DMARC Rejecting Your Own Email? Fix It Fast

Why DMARC rejects your own email

If DMARC is rejecting legitimate email from your domain, the problem is almost always alignment. DMARC does not ask whether the message looks useful. It asks whether the visible From domain is authenticated by SPF or DKIM, and whether that authenticated domain aligns with the From domain.

A message can come from a real employee, a real app, or a real vendor and still fail DMARC if it sends with your From address but uses the vendor's envelope domain, lacks a DKIM signature for your domain, or signs with a different domain. With p=reject, your DMARC record asks receivers to reject mail that fails DMARC. Receivers can still apply local policy, but you should treat a reject policy as active enforcement.

Start by checking the actual failing message headers. Look for Authentication-Results. You need at least one of these to be true: SPF passes and the SPF domain aligns with the visible From domain, or DKIM passes and the DKIM d= domain aligns with the visible From domain. A free InboxRadar domain check can also show whether the public SPF, DKIM, DMARC, and MX records are sane before you dig into individual headers.

The safe fix order

Do not start by deleting DMARC. Fix the sending path, then tighten policy again. This keeps spoofing protection in place while you restore legitimate delivery.

• Temporarily change DMARC from p=reject to p=none only if good mail is actively bouncing and you cannot fix the source immediately. Keep rua=mailto:... reporting on.
• List every legitimate sender: Google Workspace, Microsoft 365, CRM, help desk, billing, marketing platform, website forms, scanners, and any app that sends as your domain.
• Fix SPF for systems that use your domain in the envelope sender. Publish one SPF TXT record only. Include every authorized service, stay under the RFC 7208 10 DNS lookup limit, avoid +all, and choose ~all or -all deliberately. ~all is softfail, -all is hardfail, and neither replaces DMARC alignment.
• Fix DKIM for every service that supports it. Turn on signing in the provider, publish the selector record it gives you, then confirm the message carries a passing DKIM signature with a d= domain that aligns with your From domain.
• Prefer DKIM alignment for third-party senders. SPF often breaks through forwarding and many vendors use their own bounce domain unless you configure a custom return-path.
• Check MX only for receiving mail. MX records do not make outbound DMARC pass, but a broken domain setup can cause replies, bounces, and verification mail to fail.
• Check blocklists and reputation after authentication. Gmail and Outlook can still send authenticated mail to spam based on reputation, complaints, content, recipient engagement, and local filtering.

Records that usually solve it

The exact values come from your providers, but the shape should look familiar.

Your SPF record lives as a TXT record on the domain used by the SPF check, often the envelope sender or return-path domain. A typical Google Workspace example is v=spf1 include:_spf.google.com ~all. If you also send through another provider, add that provider's include only if it is a real sender. Do not publish multiple SPF records for the same name.

Your DKIM record lives at a selector name such as selector1._domainkey.example.com. The selector must match the selector in the message's DKIM-Signature header. If you migrated from one platform to another, old selectors can remain in DNS, but current mail must be signed by the active platform.

Your DMARC record lives at _dmarc.example.com. A recovery record might be v=DMARC1; p=none; rua=mailto:dmarc@example.com. Once reports show all legitimate sources passing and aligned, move to p=quarantine, then p=reject. Microsoft documents this gradual rollout pattern, and Google says bulk senders need SPF, DKIM, and DMARC with direct mail aligned to SPF or DKIM.

If you want the standards, use RFC 7208 for SPF, RFC 6376 for DKIM, and RFC 7489 for DMARC. For current receiver expectations, use the official Google sender guidelines and Microsoft email authentication guidance rather than a random DNS snippet from a forum.

Common hidden causes

The hard cases are usually not DNS typos. They are mail streams no one remembered existed.

• A CRM sends as sales@example.com but signs as the CRM's domain, so DKIM passes but does not align.
• A website form uses your domain in From instead of using a verified sender and putting the visitor in Reply-To.
• Microsoft 365 or Google Workspace has DKIM disabled after a domain migration.
• A marketing platform needs a custom DKIM domain and custom return-path before DMARC can pass.
• An SPF record grew past 10 DNS lookups because several vendors were added over time.
• A forwarded message fails SPF. DKIM may still pass if the forwarder did not alter signed headers or body content. ARC can help receivers evaluate some forwarded mail, but it is not a substitute for fixing your own source authentication.