The essentials
Map the sender identities first
An email can carry several domain identities. The address displayed beside the sender’s name is the visible From address. The SMTP envelope sender is used during delivery and normally appears in the delivered message’s Return-Path. DKIM adds a signing domain, shown by the d= value in its signature. These domains can differ.
Start by recording the identities your intended sending route uses. This prevents a common mistake: checking a record for one domain while the actual message is being evaluated against another. The Reply-To address directs replies; it is not the identity DMARC aligns with.
Also identify who controls DNS and who operates each legitimate sending workflow. An existing domain may support customer service, billing or other important mail. Your outreach setup should be understood alongside those uses. You can gather this information without changing any records.
A closer look
Give each authentication check its own job
SPF, DKIM and DMARC answer related questions. Treating them as three interchangeable green ticks hides the information you need when something fails.
DMARC also lets a domain owner express a handling policy for failed authentication and request reports. Its authentication result and the final delivery decision are separate things: a receiver still applies its own assessment.
| Check | What it checks | What it does not establish |
|---|---|---|
| SPF | Whether the sending server is authorised for the envelope-sender domain. | That the visible From domain matches that identity. |
| DKIM | Whether the message has a valid signature for a signing domain and the signed parts verify. | That the signing domain matches the visible From, or that the message deserves an inbox placement. |
| DMARC | Whether at least one passing SPF or DKIM identity aligns with the visible From domain. | That the recipient wants the email or that every other delivery requirement is satisfied. |
A closer look
Check alignment as well as authentication
For DMARC to pass, a successful check must connect to the domain in the visible From address. An SPF pass for an unrelated envelope domain does not establish that connection. The same is true of a DKIM pass from an unrelated signing domain.
Relaxed alignment allows the authenticated domain and the visible From domain to share the same organisational domain. Strict alignment requires the domains to match exactly. The applicable DMARC configuration determines which mode is used for each method.
| Observed result | Alignment | DMARC outcome |
|---|---|---|
| SPF passes for example.net; DKIM fails. | No passing identity aligns with example.org. | Fail. |
| SPF passes for example.net; DKIM passes with d=example.org. | The passing DKIM identity matches exactly. | Pass through DKIM. |
| SPF passes for return.mail.example.org; DKIM is absent. | SPF can align in relaxed mode when example.org is the shared organisational domain. | Pass in that relaxed case; fail under strict SPF alignment. |
Worked example
Read an example receiver result
This shortened example uses reserved example domains and invented results to demonstrate the structure. It is not a test result or a DNS record. Assume the result was added by the trusted receiving system and example.org is the shared organisational domain.
From: Alex <alex@example.org>
Authentication-Results: mailer.example.net;
spf=pass smtp.mailfrom=return.mail.example.org;
dkim=pass header.d=example.org;
dmarc=pass header.from=example.org- Visible identity
From shows example.org, the domain DMARC needs to connect to a passing authentication result.
- Receiving system
mailer.example.net identifies the system reporting these results. The presence of an Authentication-Results header alone does not make it trustworthy.
- SPF result
The envelope domain passed SPF. It aligns with example.org in this relaxed example, but would not match under strict SPF alignment.
- DKIM result
The passing signature uses example.org. That is an exact match, so it can support DMARC even if strict SPF alignment is required.
- DMARC result
The receiver reports a pass for the visible From domain. This describes authentication for this message, not a promise about future delivery.
Put it into practice
Verify a message from the route you will use
A DNS lookup shows published configuration. A received test message shows how a particular route used that configuration. Keep both pieces of evidence together; a successful test from your everyday inbox does not verify a different campaign route.
- 01
Choose the route. Record the sending domain, mailbox and workflow that will send the campaign. Use the intended From identity.
- 02
Send an authorised test to a mailbox you control. Use the actual sending workflow, rather than forwarding an old message or sending through an unrelated inbox.
- 03
Open the original message. In Gmail on the web, open the message, select More beside Reply, then Show original. Other receiving services provide a message-source or header view.
- 04
Record the evidence. Capture the time, recipient service, visible From domain, envelope domain, signing domain and the receiver’s SPF, DKIM and DMARC results.
- 05
Confirm alignment with the technical owner. Establish which passing method supports DMARC and whether the expected relaxed or strict setting applies.
- 06
Repeat for each intended route. Retest after relevant sending or DNS changes, and retain the result with the route it describes.
A closer look
Use a failure to narrow the next check
A failed result is a starting point for diagnosis. Give the technical owner the actual message and route, then use the table to frame the next question. An explanation should lead to a fresh test of the affected route.
| What you see | What to check next |
|---|---|
| SPF fails | Was the observed sending source authorised for the envelope domain? Did forwarding change the route? |
| SPF returns permerror | Ask the DNS owner to check the evaluated domain for invalid or multiple SPF records and lookup-limit problems. |
| DKIM is missing or fails | Check whether this route signs messages, whether the expected key is available and whether signed content changed in transit. |
| SPF and DKIM pass, but DMARC fails | Compare the authenticated domains with the visible From and inspect the required alignment modes. |
| Records exist, but the message fails | Confirm the actual sending identity, selector and route match the configuration being checked. |
| All three pass, but mail is filtered | Investigate the wider delivery picture, including reputation, recipient feedback and the receiver’s other requirements. |
A closer look
Understand the receiver’s requirements
Passing DMARC and meeting a mailbox service’s sender requirements are related, but the requirements can go further. The authentication requirements below are scoped to the consumer receiving services named, not every organisation using Google Workspace or Microsoft 365.
| Receiving service and scope | Authentication requirements |
|---|---|
| Personal Gmail accounts: all senders | Google requires SPF or DKIM authentication. |
| Personal Gmail accounts: bulk senders | Google requires SPF and DKIM, plus DMARC. For direct email, the visible From must align with SPF or DKIM. A monitoring policy of p=none is permitted. |
| Microsoft consumer services: high-volume senders | Microsoft requires both SPF and DKIM to pass, a DMARC record and a DMARC pass through at least one aligned method. Its guidance permits p=none. |
Put it into practice
Turn the check into an accountable handover
Save a short record that another person can understand. “Authentication is set up” gives little to investigate later. A named route, dated evidence and a clear owner make the result useful when you add a mailbox, change a workflow or investigate a delivery problem.
Your next step is concrete: identify one intended route, ask for its latest message evidence and complete the handover. Your setup team can perform the technical work; you should still be able to see what was checked, what passed and what remains open.
COPY YOUR AUTHENTICATION HANDOVER
Copy this worksheet into your own document, then fill it in with your details.
AUTHENTICATION REVIEW Sending route / workflow: Visible From domain: Envelope-sender domain: DKIM signing domain and selector: EVIDENCE Test date and time: Receiving service: Original message / header reference: SPF result and evaluated domain: DKIM result and signing domain: DMARC result and aligned method: Alignment mode reviewed: OWNERSHIP DNS owner: Sending setup owner: Other legitimate sending uses checked: Outstanding issue and responsible person: Retest date / trigger: Review outcome for this route:
Complete one record per route. Keep access credentials out of the worksheet and store original messages through your normal internal process.
A FOUNDATION YOU CAN VERIFY
Know the identities. Inspect an actual message. Check authentication and alignment together. Keep the evidence with a named owner so your setup remains understandable as your sending changes.
A LITTLE MORE CLARITY
Your questions, answered.
Can SPF and DKIM pass while DMARC fails?+
Yes. The passing domains may both be unrelated to the visible From domain, or fail the required alignment mode. DMARC needs at least one method that both passes authentication and aligns. Read the domains beside the results, not just the pass labels.
Does p=none mean DMARC is switched off?+
No. It expresses a monitoring policy rather than requesting quarantine or rejection for a DMARC failure. Messages can still pass or fail DMARC. Receiving services continue to make their own delivery decisions, and reporting needs its own configuration.
Does passing authentication guarantee inbox placement?+
No. Authentication helps establish authorised domain use. Receivers also assess other signals, and a recipient can still find an authenticated message unwanted. Treat a pass as evidence about identity, then review the rest of your sending practice.
Why configure both SPF and DKIM if DMARC can pass through one?+
DMARC’s pass condition is only one part of the requirements. Gmail’s bulk-sender guidance requires SPF and DKIM, and Microsoft’s consumer high-volume guidance requires both to pass. Check the rules for the receiving services you intend to contact.
Do I need to manage the DNS work myself?+
No. A responsible technical team can manage setup and verification. Ask for a route-specific handover containing the actual message results, alignment and change owner. That gives you a clear review without requiring you to edit operational records.
Sources and further reading
- Microsoft: email authentication and sender identities
- IETF RFC 9989: DMARC and identifier alignment
- Google Workspace: DMARC policies and alignment
- IETF RFC 8601: Authentication-Results and trusted receiving systems
- Google: view a message’s full headers in Gmail
- Microsoft: troubleshoot SPF, DKIM and DMARC failures
- Google: email sender requirements for personal Gmail accounts
- Microsoft: authentication requirements and error 550 5.7.515 in Outlook.com