Your message can pass Sender Policy Framework (SPF) and still fail Domain-based Message Authentication, Reporting, and Conformance (DMARC). That is the problem to solve when you need to know how to fix SPF alignment. The straight answer: the domain used by SPF must align with the domain your recipient sees in the visible From address, or a properly aligned DKIM signature must pass instead.
This distinction matters when you send invoices, appointment reminders, proposals, newsletters, or routine client updates. A receiving mailbox provider does not judge SPF in isolation. Under DMARC, it checks whether the technical identity behind the message matches the identity your customer sees.
What SPF alignment actually means
SPF is a DNS-based record that names the mail servers and services allowed to send email for a domain. It evaluates the envelope sender, often shown in technical headers as Return-Path or MAIL FROM. It does not directly validate the visible From address in the inbox.
For example, a message may show this to a recipient:
`From: billing@yourcompany.com`
But its return-path might be:
`bounce@mailer-service.example`
If the sending service passes SPF for `mailer-service.example`, SPF itself passes. However, it is not aligned with `yourcompany.com` in the visible From address. If no aligned authentication method passes, DMARC can fail.
DMARC is the policy and reporting standard that ties authentication to the visible From domain. It passes when at least one of these conditions is true:
- SPF passes and the SPF domain aligns with the visible From domain.
- DomainKeys Identified Mail (DKIM) passes and the DKIM signing domain aligns with the visible From domain.
DKIM is a cryptographic email signature. It lets a receiving server verify that an authorized domain signed the message and that key parts of it were not changed after signing.
In plain language, SPF answers, "Was this server allowed to send for this return-path domain?" DMARC asks, "Does that authenticated domain match the brand shown in From?"
Find the domain that is failing alignment
Start with a real message that failed DMARC or landed somewhere unexpected. Open the full message headers, then identify three values:
- The visible `From:` domain.
- The `Return-Path:` or `MAIL FROM` domain evaluated by SPF.
- The `d=` domain in the DKIM results, if the message has a DKIM signature.
Suppose the visible From address is `news@northstarrealty.com`, while the return-path is `northstarrealty.bounces.emailvendor.com`. SPF may pass for the vendor domain, but SPF alignment may fail because the domains are different.
Next, look for an authentication-results line. It commonly reports results in a format similar to `spf=pass`, `dkim=pass`, and `dmarc=fail`. The useful detail is not just pass or fail. You need to see which domain was checked for SPF and which domain signed with DKIM.
Do not assume a passing SPF result fixes the problem. The exact issue is the relationship between domains.
Choose the right way to fix SPF alignment
There are two normal paths. Which one is right depends on your email provider and how it handles return-path domains.
Option 1: Use a custom return-path domain
Many email platforms let you configure a custom sending or bounce domain. This is often called a custom MAIL FROM domain, custom return-path, or branded bounce domain. It may use a subdomain such as `mail.yourcompany.com` or `send.yourcompany.com`.
If your visible From address is `updates@yourcompany.com`, a return-path of `bounce@mail.yourcompany.com` is aligned under relaxed alignment rules. Both domains share the same organizational domain, `yourcompany.com`.
The provider will usually give you DNS records to add. Those may include a CNAME record, which points one domain name to another, or a TXT record, which stores verification or policy text. Add the records exactly as supplied, then complete the verification process in the sending platform.
This is the cleanest SPF alignment fix when your provider supports it. It preserves a consistent domain identity across the message and gives you more control over authentication.
Option 2: Configure aligned DKIM
Some services use their own return-path domain and do not offer custom SPF alignment. In that case, you may not be able to make SPF align. That does not automatically mean your mail will fail DMARC.
Configure the service to sign messages with DKIM using your domain or a subdomain of it. If the visible From address is `yourcompany.com`, a DKIM signing domain such as `yourcompany.com` or `mail.yourcompany.com` can align under relaxed settings.
Most established business email and marketing platforms provide DKIM setup instructions and DNS records. The records are commonly CNAME entries or TXT entries using a selector, which is a label that identifies a specific DKIM key. Once the records are published and verified, send a fresh test message. Older messages will not gain a DKIM signature after the fact.
For many organizations, aligned DKIM is the practical solution for third-party sending platforms. SPF can remain unaligned as long as aligned DKIM passes consistently.
Check whether DMARC uses relaxed or strict alignment
DMARC can use relaxed alignment or strict alignment. This setting changes what counts as a match.
Relaxed SPF alignment allows related subdomains. For example, `mail.yourcompany.com` can align with `yourcompany.com`. Strict SPF alignment requires an exact domain match. The same applies to DKIM alignment.
In your DMARC record, the `aspf` tag controls SPF alignment and the `adkim` tag controls DKIM alignment. A value of `r` means relaxed. A value of `s` means strict. If those tags are absent, relaxed alignment is the normal default.
Strict alignment can be appropriate when you have a tightly controlled sending environment. But it creates more opportunities for legitimate mail to fail when different departments, platforms, or vendors use subdomains. Do not change from relaxed to strict simply because strict sounds more secure. First confirm every authorized sender can meet that requirement.
Fix the SPF record without creating a new problem
SPF alignment and SPF authorization are related, but they are not the same repair. Once you set up a custom return-path domain, it needs an SPF record that authorizes the platform sending mail for that domain.
An SPF record is published as a TXT record in the Domain Name System (DNS), the public directory that tells the internet how to handle your domain. A basic record might authorize your Microsoft 365 or Google Workspace service, your website host, and an approved email platform.
Be careful with multiple SPF records. A domain should have one SPF TXT record. Publishing separate records for separate vendors can cause SPF to return a permanent error instead of a pass. Combine approved sources into one record where possible.
Also watch the SPF lookup limit. SPF permits a maximum of 10 DNS lookups during evaluation. Adding too many `include:` mechanisms can push your record over that limit, especially when one vendor includes several other domains behind the scenes. A record can look correct and still fail at recipients because it exceeds the lookup limit.
Do not add every service your business has ever used. Remove providers that no longer send mail for the domain, but verify first. An old platform may still send password resets, support tickets, forms, or scheduled notices.
Test every sending path, not just employee email
A common mistake is fixing SPF alignment for one platform while another continues to send unauthenticated mail. Make an inventory of every system that sends as your domain. This often includes employee mailboxes, marketing software, customer relationship management tools, website contact forms, invoicing systems, scheduling software, help desks, and copier or scanner devices.
For each system, confirm the visible From domain, return-path domain, SPF result, DKIM signing domain, and DMARC result. If a platform sends using its own return-path, make sure aligned DKIM is in place. If it supports a branded return-path, decide whether that configuration is worth the DNS work and ongoing administration.
Allow time for DNS changes to publish. Then send new tests through each source and review the actual message headers. A provider dashboard may say a domain is verified, but the receiving mailbox headers show what happened on the delivered message.
Avoid changes that cause legitimate mail to fail
Do not remove existing SPF mechanisms before you know what uses them. Do not replace a working SPF record with a vendor's sample record without merging it carefully. And do not tighten your DMARC policy while your sending inventory is incomplete.
DMARC reports can help identify sources that are still sending as your domain. They are useful, but they can be technical and do not always identify a business system by a friendly name. Match report data against your internal list of tools and vendors before making a DNS change.
If a vendor cannot support a custom return-path or aligned DKIM, consider sending with a different visible From domain only if that change makes business sense. For example, a clearly labeled subdomain may be appropriate for marketing mail, but changing the From domain can confuse customers if it is not planned carefully.
The practical goal is not to force every message through one technical setup. It is to ensure every legitimate source can pass DMARC through aligned SPF, aligned DKIM, or both.
Your next step is to run MailArrive's free email health check and review the Report Card. It can show whether your SPF, DKIM, and DMARC records are present and where your domain needs an exact fix.