Feilsøke problemer med e-postautentisering
Sist oppdatert: mai 9, 2024
Gjelder for:
Markedsføring Hub Starter , Professional , Enterprise |
Salg Hub Starter , Professional , Enterprise |
Service Hub Starter , Professional , Enterprise |
Content Hub Starter , Professional , Enterprise |
Hvis du støter på problemer når du konfigurerer e-postgodkjenning i HubSpot, kan du prøve å følge trinnene i avsnittene nedenfor for å løse vanlige SPF- og DMARC-problemer.
Feilsøking av SPF
For å konfigurere SPF på riktig måte må du legge til en TXT-post i DNS-leverandøren din og kopiere over HubSpots include-setning. Lær mer om noen av de vanligste SPF-konfigurasjonsfeilene i avsnittene nedenfor.
Flere SPF-poster
Hvis du også sender e-post via en annen e-postleverandør i tillegg til HubSpot, kan det hende du allerede har en eksisterende SPF-post satt opp i DNS-leverandøren din. Hvis dette er tilfelle, kan du legge til HubSpots SPF-post etter eventuelle eksisterende include:
-oppføringer i samme TXT-post.
Følgende eksempel viser hvordan en TXT-post kan konfigureres med flere SPF-oppføringer ved hjelp av en leverandør som GoDaddy:
Oppføringstype | Vert | Nødvendige data |
TXT | @ | v=spf1 include:anotherprovider.com include:123456.spf03.hubspotemail.net -all |
Husk følgende når du kombinerer SPF-poster:
- Hver
include:
-oppføring skal være atskilt med et mellomrom. - Du kan ha opptil 10
include:
-oppføringer for et gitt domene eller underdomene. - SPF-versjonen (
v=spf1
) trenger bare å angis én gang, i begynnelsen av oppføringen. -all
-flagget trenger bare å inkluderes én gang. Dette flagget angir at bare serverne som er oppført i SPF-posten, er autorisert til å sende e-post på vegne av domenet. E-post fra en server som ikke er oppført, skal avvises.
Hardkodede IP-adresser
HubSpots SPF-post som vises på siden for oppsett av domenet som sender e-post, er skrevet på en slik måte at den automatisk henter alle IP-adresser som kontoen din sender e-post fra. Dette sikrer at du ikke trenger å oppdatere posten i DNS-leverandøren din når du har konfigurert den.
Hvis SPF-oppføringen din inneholder andre hardkodede IP-adresser fra andre e-postleverandører, kan det oppstå feil med SPF-autentiseringen. Det anses ikke som beste praksis å hardkode IP-adresser eller CIDR-er i SPF-oppføringen. Hvis du har hardkodede adresser eller CIDR-er i SPF-oppføringen:
- Gå gjennom innholdet i SPF-posten og fjern eventuelle hardkodede HubSpot IP-adresser eller CIDR-er. Du kan følge instruksjonene i denne artikkelen for å finne en liste over HubSpots avsenderadresser og CIDR-er som du kan bruke til kryssreferanser.
- Hvis du trenger å vedlikeholde andre fastkodede IP-adresser (f.eks. hvis du har en annen tredjepartsleverandør av e-posttjenester), bør du legge til HubSpots
include:
-setning på slutten av alle fastkodede adresser, etterfulgt av-all
-flagget. Du kan se syntaksen i eksempelet på SPF-post med plassholderverdier nedenfor:
v=spf1 ip4:.../24 ip4:.../24 include:123456.spf01.hubspotemail.net -all
DMARC feilsøking
En DMARC-post består av en TXT-post som du kan tilpasse basert på hvordan du vil at innboksleverandørene skal behandle e-post fra domenet ditt som ikke klarer SPF- og DKIM-kontrollene. Avsnittene nedenfor beskriver vanlige problemer med DMARC-konfigurasjon.
Flere poster
For å sikre at DMARC er riktig konfigurert, bør du bare ha én TXT-post som begynner med versjonsflagget (f.eks. v=DMARC1
). Hvis det finnes flere DMARC-poster, vil den mottakende e-postserveren umiddelbart avslutte policyoppdagelsesprosessen, og DMARC-policyen din vil ikke bli brukt.
Nødvendige DMARC-tagger mangler
Selv om noen DMARC-policytagger er valgfrie, må du angi versjons- og policytaggene (f.eks. v=DMARC1; p=YOUR_POLICY_VALUE;
).
Du kan se alle tilgjengelige DMARC-tagger og verdiene du kan definere for dem, i oversikten over e-postgodkjenning.
Ugyldig DMARC-policyverdi
Hvis du oppdager en ugyldig DMARC-policyfeil når du konfigurerer e-postavsenderdomenet ditt i HubSpot, skyldes det sannsynligvis en ugyldig policyverdi for p
eller sp
-taggen. De eneste verdiene som er gyldige er none
, reject
, eller quarantine
. Disse verdiene er sensitive for store og små bokstaver og må skrives med små bokstaver.
Feil | Riktig |
p=Quarantine; |
p=quarantine; |
Ugyldig rapporteringsadresse
Taggene ruf
og rua
er valgfrie parametere for å angi en e-postadresse som DMARC-rapporteringsdata skal sendes til. Hvis du har angitt en verdi for en av taggene, må e-postadressen du oppgir, være gyldig og riktig formatert:
- E-postadressen du oppgir, må være i URI mailto-format, noe som krever at du prefikserer e-postadressen med
mailto:
(f.eks.mailto:reporting@example.com
). - Både
rua
- ogruf
-taggene støtter flere e-postadresser for rapportering, så lenge de er atskilt med et komma. Følgende vil for eksempel angi to forskjellige e-postadresser for rapporteringsformål:
rua=mailto:reporting@example.com,mailto:analytics@example.com;
- Den eneste gyldige verdien for
rua
- ellerruf
-taggen er en e-postadresse (eller flere adresser). Hvis du bare inkluderer et domenenavn (f.eks.rua=example.com
), vil det ikke bli ansett som gyldig.
Feil | Riktig |
rua=reporting@example.com; |
rua=mailto:reporting@example.com; |
Ugyldig DMARC-justeringsmodus
Flaggene adkim
og aspf
angir justeringsmodusen for DKIM og SPF. Begge flaggene bør settes til r
for en avslappet justering. For de fleste DNS-tjenester bør dette være standardinnstillingen for DMARC.
Feil | Riktig |
adkim=s; aspf=s; |
adkim=r; aspf=r; |
Ugyldig DMARC-prosentformat
pct-flagget brukes til å angi prosentandelen av det totale antallet unike sendinger som ikke klarte autentisering, og som policyen din skal gjelde for. Verdien du angir, skal være et tall og skal ikke inneholde noen tilleggstegn (dvs. at %-symbolet ikke skal inkluderes).
Feil | Riktig |
pct=25%; |
pct=25; |