Three checks, different jobs
SPF declares which sending mail systems are authorized for a domain used in the message envelope. DKIM adds a cryptographic signature that receivers can validate using a DNS public key. DMARC evaluates whether authentication aligns with the user-visible From domain, then requests a policy for failures.
Why one SPF line isn't enough
A record such as v=spf1 include:_spf.example.net ~all is only a starting point. Included domains can trigger additional DNS lookups; SPF has a lookup limit. Publishing multiple SPF records for the same name can cause errors. Don't remove a sender you haven't inventoried, especially when CRM, invoicing and transactional apps share your domain.
Safer DMARC rollout
Common operational stages are p=none for monitoring, then p=quarantine, then p=reject as alignment is validated. A monitoring policy doesn't actively reject impersonation attempts. Moving to reject before all mail sources align can disrupt legitimate mail.
v=DMARC1; p=none; rua=mailto:[email protected] # Later, after reviewing legitimate sender alignment: v=DMARC1; p=quarantine; rua=mailto:[email protected]
Never paste secrets or private email contents into a public tool. Our browser-only policy reviewer accepts DNS TXT policy text and does not verify live DNS or DKIM.
How to get useful answers
Paste the actual SPF and DMARC TXT values into the email policy clinic. It will flag obvious issues and explain what to verify in your DNS provider or mail service before changing production records.