A DMARC failure means a message claiming to be from your visible From domain did not pass aligned SPF or aligned DKIM under your domain’s DMARC policy. It is a diagnostic result, not an instruction to rewrite DNS immediately. The safest response is to identify the sender, compare the message headers with your authorized-sender inventory, and decide whether the source is legitimate.
Read the three identities together
In the headers, note the visible From domain, the return-path domain used for SPF, and the d= domain used for DKIM. DMARC checks whether a passing SPF or DKIM identity aligns with the visible From domain. A technical SPF pass can still leave DMARC failing when it passes for a different domain.
Run a free Beacon domain check to review the published records, then use a fresh message from the affected platform as the test case.
Most common explanations
- A new CRM, billing tool, or help desk is sending without domain authentication.
- The sender has SPF authorization but no aligned DKIM signature.
- The From address uses your root domain while the provider uses an unrelated return-path and signing domain.
- The DMARC record or DNS zone was changed incorrectly.
- An unknown service or attacker is impersonating your domain.
Diagnose before enforcing
- Identify the sending provider from the message headers.
- Check whether it is on your approved inventory.
- For an approved service, follow its official custom-domain, SPF, and DKIM setup instructions.
- For an unknown service, investigate rather than adding it to SPF.
- Test a fresh direct message after DNS propagation.
Read how to check your DMARC record for record details and the DMARC policy guide before changing enforcement.
Example
A booking tool sends reminders from appointments@yourcompany.com. It has not been configured with your DKIM domain, so the visible From domain does not align with a passing identifier. DMARC failure follows. Configure the platform’s authenticated sending domain, publish exactly the records it requires, and retest. Do not change your whole DMARC policy based on that one service.
What policy changes do—and do not—do
p=none gathers evidence; p=quarantine asks receivers to treat failures suspiciously; p=reject asks them to refuse failures. A stronger policy can reduce exact-domain spoofing, but it can also disrupt an overlooked legitimate sender. Move forward only after your sender inventory and tests support it.
When DMARC passes but delivery is poor
DMARC confirms identity, not recipient interest. If the message is authenticated but goes to spam, review list consent, bounces, complaints, volume, and content. DMARC-compliant but still going to spam covers that separate diagnosis.
Check the active DNS and report destination
Confirm that the DMARC record is published at _dmarc.yourdomain.com in the active DNS zone and that there is only one effective record. If you receive aggregate reports, use them to look for sending sources and alignment patterns over time; they are evidence, not a list of instructions to authorize every IP. A source may belong to a vendor, a former employee’s tool, or an attacker. Compare it with the client’s approved-sender inventory before changing SPF or policy.
Make one controlled change
For a legitimate sender, follow its domain-authentication procedure, preserve the old DNS value, and retest direct mail after propagation. For an unauthorized source, remove access or investigate account security rather than adding permission. Record the owner, reason, date, and result. This prevents the next DNS editor from undoing a valid control because the record looks unfamiliar.
Bring the business owner into the decision
A DMARC policy affects customer communication, so include the person responsible for billing, support, marketing, and IT when the affected sender has business importance. Explain the tradeoff plainly: enforcement can stop more exact-domain impersonation, but an untested legitimate sender can be interrupted. Agree on a test window, a rollback owner, and the evidence required before increasing enforcement. That converts a DNS change into a manageable business decision.
Use a short checklist for each sender: visible From domain, SPF result, DKIM result, alignment result, business owner, test date, and rollback route. It prevents a policy debate from being driven by a vague “pass” or “fail” rather than evidence.
After the change, check a real password reset, receipt, support reply, and campaign message if those systems use the domain. Keep the results with the sender inventory. The next vendor addition should follow the same path before it is allowed to send at scale.
FAQ
Does DMARC failure always mean spoofing?
No. A common cause is an unconfigured legitimate third-party sender.
Should I remove DMARC while investigating?
No. Keep the policy appropriate to your evidence and fix the specific sender; do not abandon the control as a shortcut.