Authenticate your sending domain

Authentication records tell receiving mail servers that your sending domain has authorised your sending infrastructure. Without them, mail goes to spam or gets rejected. This guide covers what each record does and how to set it up.

1. Identify your sending domain

   Your sending domain is the domain in your email’s “From” address — for example, if you send from hello@mail.example.com, your sending domain is mail.example.com. Go to Deliverability in InboxEagle and open your brand to see the current authentication status for each domain.

2. Set up or verify each authentication record

   Work through each tab below for your sending domain. You’ll need access to your DNS provider to add or update records.

3. Verify in InboxEagle

   After adding or updating your DNS records, allow up to 48 hours for DNS propagation. Then check Deliverability — the authentication section will show the current pass/fail status for each record.

4. Advance your DMARC policy

   Once SPF and DKIM are confirmed passing, advance your DMARC policy from none to quarantine, and eventually to reject. This is the key final step to protect your domain from spoofing.

Note

Move through DMARC stages gradually over several weeks. Monitor for legitimate mail being incorrectly rejected (check rua aggregate reports) before advancing the policy.

Authentication record details

SPF

SPF (Sender Policy Framework) is a DNS TXT record that lists the mail servers authorised to send on behalf of your domain.

What it does: When a receiving server gets your email, it checks if the sending IP is in your SPF record. If it isn’t, SPF fails.

Format:

v=spf1 include:your-esp.com ~all

Common mistakes:

• More than one SPF record on the same domain (only one is allowed — merge them).
• Missing your ESP’s include (check your ESP’s documentation for the correct include: value).
• Using -all (hard fail) before confirming all legitimate sending sources are included.

Steps:

1. Find your ESP’s SPF include value in their documentation.
2. Check if your domain already has an SPF record (dig TXT yourdomain.com).
3. Add or update the TXT record at your DNS provider.
4. Verify it in InboxEagle’s deliverability view.

Tip

Use ~all (soft fail) while setting up. Switch to -all (hard fail) once you’re confident all your sending sources are covered.

DKIM

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to your outgoing emails. The receiving server verifies the signature using a public key published in your DNS.

What it does: Proves the email was not altered in transit and was sent by an authorised sender.

Format: A TXT record at a selector subdomain:

selector._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=<public-key>"

Common mistakes:

• Not enabling DKIM signing in your ESP (most ESPs require you to enable it, not just add the DNS record).
• Using a DKIM key shorter than 1024 bits (use 2048-bit keys when available).
• Not adding the CNAME or TXT records your ESP provides.

Steps:

1. In your ESP, find the DKIM setup section and generate or locate your DKIM key.
2. Add the CNAME or TXT record your ESP gives you to your DNS.
3. Enable DKIM signing in your ESP’s settings.
4. Verify in InboxEagle that DKIM is passing.

DMARC

DMARC (Domain-based Message Authentication, Reporting & Conformance) ties SPF and DKIM together and tells receiving servers what to do when a message fails both checks.

What it does: Specifies whether to deliver, quarantine, or reject messages that fail SPF and DKIM alignment. Also enables reporting so you can see who is sending on behalf of your domain.

Format:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

DMARC rollout stages:

Stage	Policy	When to use
1. Monitor	p=none	Start here. Collect reports without affecting delivery.
2. Quarantine	p=quarantine	After confirming all legitimate mail is SPF/DKIM aligned.
3. Reject	p=reject	Final stage. Unauthenticated mail is rejected outright.

Caution

Do not skip the p=none monitoring stage. Jumping straight to p=reject without reviewing aggregate reports (rua) can cause legitimate mail to be rejected if any sending source is missing SPF or DKIM alignment.

Common mistakes:

• No rua reporting address (you won’t know what’s failing).
• Advancing to p=reject before all mail sources are authenticated.
• Applying DMARC to a domain that has no SPF or DKIM set up yet.

Steps:

1. Add a p=none DMARC record with an rua address to start receiving reports.
2. Review aggregate reports for 1–2 weeks. Confirm all mail sources are aligned.
3. Advance to p=quarantine and monitor for a further 1–2 weeks.
4. Advance to p=reject once confident no legitimate mail is failing.

Next steps

• Improve inbox placement — Beyond authentication: IP reputation, bot filtering, and send history.
• Deliverability — Check current authentication status per domain.
• Google Postmaster — Monitor domain reputation with Google’s data.