Why are my emails going to spam?

Emails land in spam when your domain is missing or misconfigured email authentication records: SPF, DKIM, and DMARC. SPF tells receiving servers which IPs are allowed to send on your behalf, DKIM adds a cryptographic signature to prove authenticity, and DMARC tells servers what to do if either check fails. InboxShield checks all three instantly and shows you exactly what to fix.

What is SPF and do I need it?

SPF (Sender Policy Framework) is a DNS record that lists which mail servers are authorised to send email for your domain. Without SPF, anyone can send email pretending to be you, and receiving servers are likely to mark your emails as spam. Every domain that sends email should have an SPF record.

DKIM (DomainKeys Identified Mail) adds a digital signature to every email you send. Receiving servers check this signature against a public key in your DNS to verify the email was not tampered with in transit. DKIM significantly improves deliverability and is required by Gmail and Yahoo for bulk senders.

What is DMARC and why does it matter?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a policy record in your DNS that tells receiving mail servers what to do when an email fails SPF or DKIM checks — either do nothing (none), quarantine to spam, or reject outright. Without DMARC, your domain is vulnerable to email spoofing and phishing attacks.

How do I check if my email deliverability is set up correctly?

Enter your domain into InboxShield and it will instantly check your SPF, DKIM, DMARC, BIMI, and MTA-STS records, flag any problems, and give you step-by-step instructions to fix them. The tool is free and requires no account.

BIMI (Brand Indicators for Message Identification) is a DNS record that displays your brand logo in the inbox of supporting email clients like Gmail and Apple Mail. It requires a valid DMARC policy and a verified logo file. BIMI increases brand recognition and email open rates.

← Blog·DMARC·December 8, 2025·6 min read

How to Read a DMARC Report: A Plain-English Guide

Once you set up DMARC with a reporting address, XML files start arriving in your inbox. They look like raw code and contain data you've probably never seen before. Here's how to decode them — and what to actually do with what you find.

What is a DMARC report?

When you add rua=mailto:dmarc@yourdomain.com to your DMARC record, major email providers (Gmail, Yahoo, Microsoft, and others) start sending you daily XML reports summarising every email they received that claimed to be from your domain.

These are called aggregate reports (RUA). There are alsoforensic reports (RUF) — individual failure reports — but aggregate reports are the most useful for day-to-day monitoring and are supported by all major providers.

Each report covers a 24-hour period and tells you:

Which IP addresses sent email claiming to be from your domain
How many messages were sent from each IP
Whether SPF and DKIM passed or failed for each sending source
What DMARC policy action was taken (none, quarantine, reject)

What the XML actually contains

The raw XML has several sections. Here's what each key section means:

Report metadata

The top of the report identifies who sent it, your domain, and the time period covered. You'll see the sending organisation (e.g., google.com or yahoo.com), a report ID, and timestamps for the start and end of the reporting period (in Unix time — you can convert with any online Unix timestamp converter).

Policy published

This confirms what DMARC policy the reporting organisation saw on your domain during the reporting period. It's a useful sanity check — if this doesn't match what you set, your DNS changes may not have propagated or a typo crept in.

p — Your current policy: none, quarantine, or reject
pct — The percentage of mail the policy applies to (default 100)
adkim — DKIM alignment mode (r=relaxed, s=strict)
aspf — SPF alignment mode (r=relaxed, s=strict)

Record (the most important section)

Each <record> block represents a distinct sending source — a unique combination of sending IP, SPF result, and DKIM result. A single report might have one record or dozens, depending on how many sources sent email claiming your domain.

Within each record, the key fields are:

Source IP — The server that sent the email. This is how you discover unauthorised senders using your domain.
Count — How many emails came from this IP during the period.
Disposition — What the receiving server did: none (delivered), quarantine (spam), or reject (blocked).
SPF result — pass or fail, and whether it aligned with the From domain.
DKIM result — pass or fail, and the selector and domain used.
Overall DMARC result — pass if either SPF or DKIM passed with alignment, fail otherwise.

How to read the report without XML expertise

Most people don't want to read raw XML. Several free and paid tools convert DMARC reports into human-readable dashboards:

Dmarcian — Popular DMARC monitoring service with a free tier
DMARC Analyzer — Provides visualisations and policy recommendations
Postmark's DMARC Report Tool — Free tool at dmarc.postmarkapp.com that parses single reports
Google Postmaster Tools — Shows authentication pass rates for Gmail specifically

These tools transform the XML into charts showing pass/fail rates by sender IP, authentication method, and time period. Even the free tiers of most services are adequate for small business monitoring.

What to look for in your reports

Unexpected sending IPs

The most valuable thing DMARC reports reveal is email being sent from IP addresses you don't recognise. These fall into two categories:

Legitimate senders you forgot to add to SPF — A CRM, invoicing tool, or help desk system sending on your behalf. Add the relevant include to your SPF record.
Phishing or spoofing attempts — Someone trying to impersonate your domain. If these emails are failing authentication, your DMARC policy is working. Consider upgrading from p=none to p=quarantine or p=reject to block them.

DKIM failures from known sources

If you see a known sending service (e.g. Mailchimp) with DKIM failures, you likely haven't completed the DKIM setup for that service — or the DKIM key has expired. Log in to that service's admin panel and regenerate the DKIM setup.

SPF alignment failures despite SPF passing

DMARC requires alignment, not just a pass. If SPF passes but the domain in the SPF result doesn't match the domain in the From header, it still counts as a DMARC failure. This is common when using third-party sending services that authenticate on their own domain unless you configure custom DKIM on your domain.

When to upgrade your DMARC policy

Use this simple decision process:

After 1–2 weeks of p=none: check reports for unexpected senders and fix any legitimate ones
Once all legitimate mail sources are authenticating: upgrade to p=quarantine
After another 2 weeks with no issues: upgrade to p=reject

A p=reject policy is the strongest protection against domain spoofing and signals to Gmail that you take your domain's email security seriously.

Before you upgrade to p=reject: Make sure every legitimate email source (newsletters, CRMs, transactional email, support tools) appears in your DMARC reports with a PASS result. If any legitimate source is failing, emails from that service will be blocked after the upgrade.

Check if DMARC is set up correctly

InboxShield Mini checks your DMARC record, policy level, and alignment in real-time. Free scan — no account required.

Run free scan