SPF, DKIM, and DMARC explained

Email authentication gives receiving providers evidence about who was allowed to send a message, whether it was signed, and whether those results match the domain visible to the recipient.

SPF, DKIM, and DMARC are related, but they answer different questions.

SPF checks whether the server that submitted a message is authorized by the policy published for the message's envelope sender domain. That technical sender is commonly visible in the Return-Path header.

A domain publishes its SPF policy as a DNS TXT record. The policy can authorize server addresses directly or refer to the records of services that send on the domain's behalf.

An SPF pass is useful, but it does not by itself prove that the domain in the visible From: address matches the authenticated domain. That connection is handled by DMARC alignment.

A domain should have one SPF record, not a separate SPF record for each sending service.

One provider might ask you to publish:

v=spf1 include:_spf.google.com ~all

Another might ask for:

v=spf1 include:mailservice.example ~all

Do not publish both as separate SPF records for the same name. Combine the services into one policy:

v=spf1 include:_spf.google.com include:mailservice.example ~all

There is another constraint: SPF evaluation has a DNS-lookup limit. Each include may trigger additional lookups behind the scenes, so a long policy can fail even when its syntax looks reasonable.

Keep one SPF record, include only services you actually use, and review the resulting lookup chain rather than counting only the text visible in the record.

DKIM adds a cryptographic signature to a message. The signature names a signing domain and selector; the receiving server uses those values to find the corresponding public key in DNS.

If verification succeeds, the receiver knows that the message was signed using the matching private key and that the signed portions were not changed after signing.

DKIM does not mean that every visible statement in a message is trustworthy. Its role is narrower: it provides a verifiable domain signature and protects the parts of the message covered by that signature.

DMARC evaluates whether SPF or DKIM passed with a domain aligned to the address visible in From:. Only one aligned mechanism needs to pass.

SPF passing and SPF alignment are separate checks:

1. SPF checks the envelope sender domain, usually shown in Return-Path or SMTP MAIL FROM.
2. SPF aligns when that domain matches the domain in the visible From: address. With relaxed alignment, a subdomain of the same organizational domain can also align.

For example:

• Visible From: [email protected]
• Return-Path: [email protected]
• SPF passes for example.com

SPF passes and the domains align, so SPF can satisfy DMARC.

If the Return-Path were instead [email protected], SPF might pass for mailvendor.com but would not align with example.com. In that case SPF would not satisfy DMARC.

DKIM follows a parallel rule. A valid signature passes DKIM, but it aligns for DMARC only when the signature's d= domain matches the visible From domain. Relaxed alignment allows the same organizational domain, including a subdomain relationship; strict alignment requires an exact domain match.

A valid DKIM signature from an unrelated service domain can therefore pass DKIM without satisfying DMARC. Either aligned SPF or aligned DKIM is enough for DMARC to pass.

If neither SPF nor DKIM passes with alignment, the receiving system consults the policy published in the domain's DMARC record:

• p=none: request no DMARC-specific enforcement action; mainly monitor.
• p=quarantine: ask receivers to treat the message as suspicious, commonly by placing it in spam.
• p=reject: ask receivers to reject the message.

These are published requests to receiving providers, not commands that every receiver must apply mechanically. In particular, p=none does not mean discard; it means not quarantining or rejecting solely because of the DMARC result.

Receiving providers such as Google and Microsoft may send aggregate DMARC reports when your _dmarc TXT record includes an address in the rua field.

These machine-readable reports summarize sources that sent messages claiming to use your domain and show their SPF, DKIM, and alignment results. Receiving a report is expected when aggregate reporting is enabled; it does not by itself mean that your domain has failed authentication or is under attack.

Use the reports to inventory legitimate senders, notice unexpected sources, and check authentication before moving from monitoring toward a stricter policy.

When configuring MailLogic, use the exact values shown in the dashboard and confirm them through the domain setup process.