Do I need DMARC if SPF and DKIM pass?

DMARC is what tells receivers those results should be enforced for your domain, and it is also where you receive reports about failures. Without it, you can pass and still have no policy, and forged mail using your domain is treated no differently.

Why does DKIM fail after I moved providers?

The selector changed. Keys are published at a selector under your domain, and a new provider signs with its own selector, which you have to publish or have the provider publish. Old records can be left in place; the new selector is what matters.

What does p=none actually do?

It asks receivers to take no action on failures while still sending you reports. It is a reasonable monitoring step before enforcement, but it gives no protection. Moving to quarantine and then reject is what turns the record into a policy.

Can I send from a subdomain with the root domain records?

Under relaxed alignment it can pass if the organisational domain matches, but strict alignment requires an exact match. Publishing SPF, DKIM and DMARC for the subdomain removes the ambiguity and is the safer setup for anything at volume.

SPF, DKIM and DMARC: Check All Three Before You Send

The short answer

SPF authorises the sending server, DKIM signs the message, and DMARC tells receivers what to do when the first two fail and whether they must match your domain. Check all three from the sending mailbox: publish SPF, sign with DKIM on the correct selector, and set DMARC alignment, not just a policy.

Authentication is checked before any spam filter reads your copy, so a failing record makes everything else irrelevant. It is also the part most often half-done: a mailbox that sends through a provider while the domain authorises a different one, or DKIM signed on a selector nobody published. Ten minutes of checking prevents weeks of wondering.

What each record actually proves

SPF is a list of servers allowed to send as your domain. The receiving server compares the IP that connected with the list in the SPF record and records a result. It says nothing about the message body and nothing about whether the sender is trustworthy, only whether that server was authorised.

DKIM is a cryptographic signature on the message, verified with a public key published at a selector under your domain. A valid signature proves the message was signed by someone holding the private key and that the signed parts were not altered in transit.

DMARC ties the two to the From domain. It says that mail claiming to be from your domain should pass SPF or DKIM with alignment, and tells the receiver what to do when it does not. Alignment is the part people miss: passing SPF as a different domain does not satisfy DMARC.

The checks to run, in order

Look up the SPF record and read it. It must be a single record, it should end in a hard fail or a soft fail rather than a permissive plus sign, it must not exceed the lookup limit, and it must include the server that actually sends your mail. Two SPF records on one domain is a fail, not a merge.

Check the DKIM selector your provider told you to use. Some providers publish a CNAME rather than a TXT record, and the CNAME must resolve. Then send a real message to a mailbox you control and read the authentication results in the header; that is the only check that proves the whole path.

One SPF record, not two, and it names the actual sending server.
DKIM selector resolves and the signature verifies in a real received message.
DMARC record exists with a policy, and alignment is relaxed or strict as intended.
The From domain matches the domain you authenticated, not a lookalike.
A test message to a mailbox you control shows all three passing.

The mistakes that survive a passing test

Sending as a subdomain is one. Mail from promo.example.com with SPF and DKIM for example.com can fail alignment under strict settings, and the fix is usually to publish the records for the subdomain too. A single test message from the wrong address will not reveal it.

The other is a forwarding loop or a mailing list that rewrites the sender. Forwarding breaks SPF by design, because the forwarder is not in your record. DKIM survives some forwarding, which is exactly why DMARC lets either one pass, and why a setup with only SPF falls apart the moment a recipient forwards.

Worked example: a domain that passed every checker and still failed

A consultant moved a client to a new SMTP provider. Every online checker showed SPF valid, DKIM valid and DMARC present, so the first campaign went out. Within a day, Gmail was placing the mail in spam and the client was asking why. The checkers had looked up records, not a message.

A test send to a Gmail mailbox settled it: SPF passed for the provider's own domain, DKIM passed on the provider's selector, and DMARC failed alignment because the From domain was the client's. The provider had been signing with its own domain unless a setting was changed, and the setting had been left at the default.

Correcting it was one toggle and one re-test. The lesson is that a lookup tool checks that records exist, not that the message you send carries their result, and the gap between those two things is where most of these problems live.

Record, what it covers, and the failure it produces

Record	Proves	Typical failure	Fix
SPF	This server may send as the domain	Too many lookups, or the wrong server listed	Flatten or simplify, include the real sender
DKIM	The message was signed and unaltered	Selector missing or key mismatch	Publish the selector the provider uses
DMARC	What to do when SPF or DKIM fail, with alignment	Policy present but alignment not met	Send as the authenticated domain
Alignment	The authenticated domain matches From	Sending as a subdomain without its own records	Publish records for the subdomain

A record that passes a lookup tool can still fail in practice; the received header from a real send is the only full test.

Before the first campaign send

1Look up the SPF record and confirm there is exactly one.
2Confirm the sending server you use appears in it.
3Check the DKIM selector resolves, including any CNAME hop.
4Send a test to a mailbox you control and read the authentication results.
5Confirm the From address uses the domain whose records you published.

Where this connects on this site

To see authentication results on a real send, use the SMTP tester
If you would rather start from a working mailbox, see SMTP accounts with authentication set up
For help reading a failure header, contact support

What this will not do

Passing all three does not guarantee inbox placement; content filters and reputation still apply.
SPF cannot survive every forwarder, which is why DMARC allows either SPF or DKIM to pass.
A DKIM key is only as private as the server holding it; a compromised server can sign as you.
These checks cover authentication, not consent or list quality, which drive complaints.

Questions this page gets asked

Do I need DMARC if SPF and DKIM pass?: DMARC is what tells receivers those results should be enforced for your domain, and it is also where you receive reports about failures. Without it, you can pass and still have no policy, and forged mail using your domain is treated no differently.
Why does DKIM fail after I moved providers?: The selector changed. Keys are published at a selector under your domain, and a new provider signs with its own selector, which you have to publish or have the provider publish. Old records can be left in place; the new selector is what matters.
What does p=none actually do?: It asks receivers to take no action on failures while still sending you reports. It is a reasonable monitoring step before enforcement, but it gives no protection. Moving to quarantine and then reject is what turns the record into a policy.
Can I send from a subdomain with the root domain records?: Under relaxed alignment it can pass if the organisational domain matches, but strict alignment requires an exact match. Publishing SPF, DKIM and DMARC for the subdomain removes the ambiguity and is the safer setup for anything at volume.

Last reviewed 2026-10-27. Written for readers in the United States and elsewhere; rules about access, email and consent differ by country, and nothing on this page is legal advice.