Fix DMARC alignment failures

A DMARC alignment failure occurs when your sending infrastructure (IP address, SPF record, or DKIM signature) does not match your DMARC policy. This guide walks you through diagnosing failures and fixing the underlying issues.

Caution

Do not jump directly to DMARC p=reject without verifying alignment first. A misconfigured DMARC policy with p=reject will block all email from your domain that doesn’t align, including legitimate messages.

1. Check your current DMARC policy

   Go to Deliverability in InboxEagle and open your brand. Scroll to the DMARC section and note:

   • Your current policy (p=none, p=quarantine, or p=reject)
   • Alignment status (passing or failing)
   • Recent failure sources (if visible)

   If your policy shows as “missing” or “not set”, you haven’t published a DMARC record yet. Start with p=none (monitor only) to collect data without blocking mail.

2. Verify SPF and DKIM authentication

   DMARC alignment requires either SPF or DKIM to pass. Before changing your DMARC policy, verify both are already passing:

   In Deliverability, check the Authentication section for your sending domain:

   • SPF — Should show “Passing”. If failing, see Authenticate your sending domain for setup steps.
   • DKIM — Should show “Passing”. If failing, verify your DKIM selector is properly configured in your DNS provider and your ESP has DKIM signing enabled.

   Tip

   You don’t need both SPF and DKIM to pass — DMARC requires alignment with at least one of them. However, having both improves your authentication posture and reputation.

3. Review DMARC aggregate reports

   If your DMARC policy is set to anything other than p=none, you should be receiving aggregate DMARC reports at your RUA (Report URI for Aggregate) email address. These reports show:

   • Which IPs sent email from your domain
   • Whether each sender passed SPF, DKIM, and alignment
   • Which senders failed and why

   Check your email inbox for reports from your email provider or use a DMARC report analyzer like Valimail or Dmarcian to parse them.

   Note

   DMARC aggregate reports are typically sent once per day. If you don’t see reports, check that your RUA address is correct in your DMARC record and that it’s reachable.

4. Identify and remove unauthorized senders

   Common sources of DMARC failures include:

   • Transactional email services — Services like SendGrid, AWS SES, or Firebase may send from third-party IPs that don’t align with your domain
   • Feedback loops — Some ESPs send feedback loop messages (bounce/complaint notifications) from auxiliary domains
   • Third-party tools — Monitoring services, password reset systems, or notification tools that send on your behalf
   • Legacy systems — Old applications sending from IPs no longer in your SPF record

   For each unauthorized sender, you have two options:

   • Add to SPF — If you control the sender, add its IP or domain to your SPF record (see Authenticate your sending domain)
   • Remove the sender — If you don’t need the sender or can’t add it to SPF, disable or remove it from your infrastructure
   • Use a subdomain — As a last resort, send from a subdomain (e.g., mail.example.com instead of example.com) with its own DMARC policy, so alignment failures don’t affect your main domain

5. Test with a more restrictive policy

   Once SPF and DKIM are confirmed passing, you can advance your DMARC policy:

   From p=none

   Change your DMARC record from p=none to p=quarantine. This tells ISPs to quarantine email that fails DMARC alignment (typically spam folder) but not reject it outright.

   v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com

   Send a small test batch through your ESP and monitor email delivery for 24–48 hours. Check:

   • Do test emails arrive in the inbox?
   • Are any legitimate emails being delivered to spam?
   • Do you see any bounce/failure notifications?

   If all tests pass and no legitimate mail is being caught, advance to p=reject.

   From p=quarantine

   If you’re already at p=quarantine and alignment is stable, advance to p=reject. This is the strongest DMARC posture and prevents spoofing:

   v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

   Again, monitor for 24–48 hours to ensure no legitimate mail is being rejected. p=reject will block mail that fails alignment without giving ISPs the option to quarantine, so it’s critical to test first.

6. Advance to p=reject (optional but recommended)

   Once you’re confident that all legitimate senders are aligned, you can set your DMARC policy to p=reject:

   v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com

   This is the strongest protection against domain spoofing and phishing. ISPs will reject (not quarantine) any email that fails DMARC alignment.

   Caution

   Do not set p=reject without first verifying SPF/DKIM alignment in quarantine mode. A misconfigured p=reject policy will block your own legitimate email.

---

Common DMARC alignment failure scenarios

Scenario 1: Transactional emails not aligned

Problem: You send transactional emails (password resets, order confirmations) through a service like AWS SES, but InboxEagle shows DMARC failures.

Cause: The service uses a third-party IP that is not in your SPF record, and you haven’t set up DKIM signing on the service.

Fix:

• Option A: Add the service’s IP range or domain to your SPF record (e.g., include:sendgrid.net for SendGrid)
• Option B: Configure DKIM signing through the service (AWS SES, SendGrid, etc. all support DKIM)
• Option C: Use a subdomain for transactional mail (e.g., noreply@transactional.example.com) with a separate DMARC policy

Scenario 2: Feedback loops failing

Problem: Your ESP sends bounce and complaint notifications, and DMARC reports show misalignment on these messages.

Cause: Feedback loop messages are sent from auxiliary systems that don’t align with your main domain.

Fix:

• Check your ESP’s documentation for feedback loop configuration
• Typically, you can configure the ESP to use a subdomain or a different domain for feedback loops
• Add that domain/IP to your SPF record if it’s under your control

Scenario 3: DMARC alignment was passing, now failing

Problem: Your DMARC alignment was working fine, but InboxEagle recently started showing failures.

Cause: Something changed in your sending infrastructure:

• You added a new ESP or sending service
• Your ESP changed its sending IP or domain
• You updated your SPF record incorrectly
• You changed your email provider

Fix:

1. Check your DMARC monitoring page for the recent failure sources
2. Identify which IP or domain is new
3. Add it to your SPF record or configure DKIM signing on the new service

---

DMARC policy progression strategy

The recommended approach is to advance your DMARC policy gradually:

Stage	Policy	Duration	Goal
1. Discovery	p=none	1–2 weeks	Collect data on senders; identify misaligned sources
2. Quarantine	p=quarantine	1–2 weeks	Route misaligned mail to spam; verify no legitimate mail blocked
3. Rejection	p=reject	Ongoing	Block all misaligned mail; maximum domain protection

Do not skip stages. Moving directly to p=reject without first testing quarantine can cause legitimate emails to bounce.

---

Monitoring after DMARC changes

After advancing your DMARC policy, monitor these metrics in InboxEagle:

• DMARC alignment rate — Should be 95%+ after fix
• Spam rate — Should not increase significantly
• Bounce rate — Watch for unexpected bounces (could indicate alignment issues)
• ISP-specific placement — Check Gmail, Yahoo, Outlook placement separately; some ISPs are stricter with DMARC

---

See also

• DMARC monitoring — Real-time DMARC failure detection
• Authenticate your sending domain — Complete authentication setup guide
• Improve inbox placement — Broader deliverability strategies