How to Set Up SPF, DKIM, and DMARC for Email Sending

Why SPF, DKIM, and DMARC Are Non-Negotiable for Sending Email

You send emails. But what if half of them never reach the inbox? Not because of poor content—but because your domain isn’t properly authenticated?

Spammers abuse weak or unauthenticated domains every day. Email providers like Gmail and Outlook rely on SPF, DKIM, and DMARC to distinguish real senders from frauds. Without them, your legitimate messages face the same filters as phishing attempts.

If you’re sending email at any scale—marketing, transactional, or support—learning how to set up SPF, DKIM, and DMARC for email sending isn’t optional. It’s required to avoid being blocked, flagged as spam, or ignored.

Key takeaways

• Spammers target unauthenticated domains; properly configured SPF, DKIM, and DMARC reduce spam risk.
• Email providers use these three protocols to assess sender trustworthiness.
• Implementing all three improves sender reputation and inbox placement.

The Core Roles of SPF, DKIM, and DMARC

Let’s cut through the confusion. SPF, DKIM, and DMARC aren’t optional extras — they’re the foundation of email deliverability. Each has a distinct role in proving your emails are legit. Think of them as a security triad: one confirms identity, one verifies content integrity, and one dictates policy enforcement.

How They Work Together

To send email from your domain — say, [email protected] — you need all three to work properly. Here’s how they stack up in real-world practice:

Understanding these roles isn’t just academic. A recent study by the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG) found that domains without DMARC are significantly more likely to be exploited in phishing campaigns. This directly affects sender reputation — and inbox placement. You’re not just setting up records. You’re building a reputation. And that reputation is what determines whether your email lands in the inbox or the junk folder. For example, if your email service provider uses a shared IP pool, SPF alone might not cover all sending servers. That’s why you need DKIM (which signs individual messages) and DMARC (to enforce policy). If you're unsure whether your domain is properly configured, use our inbox placement test to see how real inboxes react. Test real inbox delivery, or use our bulk verification tool to identify and clean invalid or poorly configured addresses before sending. A strong sender reputation starts with clean, authenticated mail.

Step-by-Step: How to Configure SPF

Setting up SPF is one of the first things you should do when sending email at scale. It tells receiving mail servers who’s allowed to send from your domain. Without it, your emails are more likely to be marked as spam.

What SPF Actually Does

SPF (Sender Policy Framework) is a DNS record that lists the mail servers authorized to send email on behalf of your domain. It helps prevent spoofing and improves deliverability.

Think of it as a digital guest list: only the hosts listed in the record get in. If someone shows up without an invite, the server says no. This is a standard way to verify sender legitimacy, as defined in RFC 7208.

1. Log into your DNS provider — Whether it’s Cloudflare, GoDns, AWS Route 53, or another service, access your domain’s DNS settings. You’ll need admin-level access to make changes.
2. Create a new TXT record — Look for an option like “Add Record” or “Create DNS Record.” Choose TXT as the record type.
3. Set the name to @ — This applies the record to your root domain. In most DNS providers, “@” means “the domain itself,” like example.com. Some also accept your domain name directly.
4. Paste the SPF value — Use this format: v=spf1 include:_spf.yourmailservice.com -all. Replace yourmailservice.com with the actual SPF include from your sending platform (e.g., sendgrid.net for SendGrid, mailgun.org for Mailgun).
5. Save the record — Confirm the change is saved. Most providers update immediately, but propagation can take 5 to 10 minutes.
6. Verify the setup — After saving, test the record using a DNS lookup tool. You can use MXToolbox to check if the record is live and valid.

Why This Matters for Deliverability

SPF is part of your sender reputation. If your domain lacks a proper SPF record, or the record is misconfigured, ISPs like Gmail and Yahoo may block your messages outright. Even a single failed SPF check can hurt inbox placement.

Some services (like Mailchimp or SendGrid) provide their own SPF includes. You don’t need to create one from scratch — just use the one they give you. Using the correct include means your sender identity checks out in real time.

If you're managing a large list, make sure to test your domain’s SPF alongside DKIM and DMARC. You can use MailTester’s inbox placement testing to simulate real-world sending and catch issues before you send to real users.

And if you’re cleaning up a list before sending, bulk email verification can help you spot invalid or problematic addresses before they hurt your reputation.

“SPF is not a magic bullet, but skipping it is a guaranteed way to reduce deliverability.” – Email deliverability guide, Return Path

Step-by-Step: How to Enable DKIM for Your Email Service

Why DKIM Matters

DKIM (DomainKeys Identified Mail) is a technical safeguard that proves your email wasn't altered in transit. Without it, inbox providers have less confidence in your messages, increasing the chance they land in spam or get blocked.

According to the IETF’s RFC 6376, DKIM uses cryptographic signatures to verify the authenticity of an email’s origin and content. It’s one of the three foundational email authentication protocols — SPF, DKIM, and DMARC — and missing it weakens your sender reputation.

Setting it Up in Your Email Service

1. Log in to your email service provider's dashboard. Whether you use SendGrid, Amazon SES, or another platform, navigate to the security or domain authentication section. This is where you’ll configure DKIM.
2. Locate the DKIM settings and generate a selector and private key. The provider will typically let you choose a selector (like s1 or mail). The selector becomes part of your DNS record name. The private key stays with your provider; you won’t use it directly.
3. Copy the public key portion. This is usually a long string starting with v=DKIM1; and containing multiple fields like k=rsa; and p=.... You'll need this exact text for your DNS record.
4. Go to your DNS zone and create a new TXT record. Use the selector as the prefix, followed by ._domainkey.yourdomain.com. For example, if your selector is s1, the record name becomes s1._domainkey.yourdomain.com. Paste the full public key into the value field.
5. Wait for DNS propagation before enabling DKIM. DNS changes can take minutes to hours to replicate globally. Until then, your email provider won’t be able to validate the signature. You can check propagation status using tools like MXToolbox or DNSChecker.org.
6. Enable DKIM in your sender settings. Once propagation is complete, return to your email service and toggle DKIM on. Some providers require you to re-verify the record before activation.

Let’s be clear: enabling DKIM doesn’t guarantee inbox delivery. But it removes a major red flag for inbox providers. A 2023 study by Return Path showed that authenticated emails had a 10–20% higher inbox placement rate compared to unauthenticated ones.

When you’re done with setup, test the configuration using a tool that checks domain records. You can also use MailTester’s Inbox Placement test to see how your authenticated messages perform in real inboxes.

Step-by-Step: How to Publish a DMARC Record

Let’s get your domain protected. DMARC is your reporting backbone — it tells receiving servers what to do with messages that fail SPF or DKIM checks. But it won’t work unless you publish a record.

Start with Monitoring: Use p=none

Begin by setting a DMARC policy that doesn’t block anything. This lets you monitor incoming feedback without risking delivery.

1. Create a TXT record for _dmarc.yourdomain.com in your DNS provider’s console. This is where the DMARC policy lives.
2. Set the value to: v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]
3. Save the record. It may take up to 48 hours to propagate, but most email providers pick it up within minutes.
4. Check the record with a tool like MXToolbox to confirm it’s published correctly.
5. Wait a few days. You’ll start receiving aggregate reports on authentication failures from major email providers.

Once you’ve reviewed the reports, you can adjust your policy based on real data. This step is critical. A misconfigured DMARC record can break email delivery.

Move to Enforcement After Review

After you’ve checked alignment, sent from valid servers, and ensured no legitimate emails are failing, you can tighten the policy.

• Change p=none to p=quarantine to mark suspicious emails as spam.
• Eventually, switch to p=reject if you’re confident your SPF and DKIM setups are consistent and your traffic is clean.
• Use the data from rua and ruf reports to check for misaligned senders or broken DKIM signatures.
• Verify your sending sources are covered by SPF and signed with DKIM — especially if you use third-party services.

DMARC enforcement only works when SPF and DKIM are correctly configured. A mismatched or missing DKIM signature will still result in a failure — even with p=reject applied.

Let’s be honest: most organizations skip monitoring and jump straight to rejection. That’s why so many companies face sudden delivery drops. Start with p=none, learn from the data, then act.

For teams managing large lists or sending across multiple domains, bulk verification tools like MailTester’s bulk verification help you validate email quality before sending — ensuring your DMARC reports reflect real, valid traffic.

Common Pitfalls That Break Email Authentication

SPF: The Hidden Traps

Let’s be honest — SPF records are one of the most commonly misconfigured parts of email authentication. You’re not alone if you’ve accidentally added duplicate records or left old ones lingering.

• Don’t create multiple SPF records in DNS. Only one is allowed per domain. If you have two, mail servers reject your email or flag it as suspicious.
• If you use multiple services (like Mailchimp, SendGrid, and your own mail server), combine their mechanisms into a single SPF record using include: statements — but never exceed the 10 DNS lookup limit.
• Use a tool like MxToolbox’s SPF Checker to validate your record before going live. A single typo can trigger hard bounces.

DKIM and DMARC: Alignment and Timing

It’s easy to rush into strict DMARC policies. But unless you’ve monitored alignment reports, you’re asking for failed deliveries — especially with shared domains or third-party senders.

• Double-check your DKIM selector. The name must match exactly what your email service provider expects. A mismatch means DKIM fails, even if everything else is correct.
• Don’t use DMARC policy=reject immediately. Start with report-only for 2–4 weeks. Let your email system generate alignment reports from major providers (like Gmail and Outlook).
• Use your DMARC aggregate reports (via dmarc.org or your email provider) to confirm that your senders are aligning and sending correctly before enforcing rejection.
• When using multiple email services, ensure each one has its own DKIM key and selector. Mixing keys between services breaks validation.

Even small missteps here can mean your messages land in spam or get dropped entirely.

“A single incorrectly configured DKIM selector can invalidate the authentication chain for every message from your domain.”

Pro tip: use MailTester’s inbox placement testing to audit how your authenticated emails perform across inboxes — real-world feedback beats theory every time.

And if you’re managing a large list and want to clean it before sending, check your domain’s health with bulk verification. It catches invalid, catch-all, and disposable addresses before they harm your reputation.

How to Test SPF, DKIM, and DMARC Configuration

Setting up SPF, DKIM, and DMARC is only half the battle. You need to verify that they’re actually working. Let’s walk through the steps to validate your setup.

Check Your DNS Records for Correct Syntax

1. Use a DNS validation tool like MXToolbox or Google’s SPF validator. These tools check your DNS records for syntax errors, such as incorrect tags, malformed domains, or excessive includes. A single typo can break authentication. For reference, RFC 7208 outlines the syntax rules for SPF; check it directly if you're debugging a complex setup.
2. Review record length and complexity. SPF records have a 1000-character limit. If your record exceeds that, you’ll need to use include delegation or split the record. Tools like MXToolbox will flag this issue in real time.

Validate Authentication in Real Email Headers

3. Send a test email from your domain using a verified account. Use a tool like MailTester’s inbox-placement test to send an email directly to multiple providers (Gmail, Outlook, etc.) and see how it’s processed.
4. View the full email headers in your recipient inbox. Look for the Authentication-Results section. It will show whether SPF passed or failed, if DKIM signature was verified, and what DMARC policy applied. A clean “pass” for both SPF and DKIM means your email is authentically tied to your domain.
5. Check for DMARC policy enforcement. The DMARC-Result line in the headers will show your domain’s policy: none, quarantine, or reject. You want to see reject if you’re aiming for strong protection. If it's none, no action is taken even if SPF or DKIM fails.

Even if your records pass syntax checks, real-world email delivery depends on how receiving servers interpret them. That’s why testing in practice matters more than theory.

Monitor DMARC reports over time. Tools like Postmark, Agari, or MailTester’s inbox-placement tests can collect and analyze DMARC aggregate reports. These reports show how many emails were authenticated, where spoofing attempts occurred, and help you refine your policy safely.

“Even a single failed SPF check can reduce inbox placement by up to 25% in high-volume sending scenarios.” — industry-observed trend from email delivery analytics

Start with low-stakes testing. Send to a controlled set of addresses, validate headers, then scale once you’re confident your configuration is correct. It’s far easier to fix issues before you’re sending to thousands.

Use your inbox-placement test not just to check deliverability, but to see how each receiving server validates your auth records. Every provider applies a different weight to these checks — knowing where you fail helps you adjust proactively.

Verifying Your Domain Isn’t on a Blocklist

Let’s be clear: even perfect SPF, DKIM, and DMARC setup won’t fix a domain that’s already on a blocklist. If your messages are being rejected at the gateway, the problem might not be your headers—it might be your history. Your sender reputation matters as much as authentication.

Use public tools like Spamhaus’s blocklist checker or Barracuda’s Real-time Blackhole List lookup to see if your domain appears. SORBS offers another trusted source for real-time reputation checks. These are not just tools—they’re industry-standard gatekeepers for email senders.

Blocklist Status Impacts Deliverability

Even with valid authentication, a domain listed on a blocklist will struggle to reach inboxes. Spam filters don’t wait for DKIM validation—they act fast. If your domain is blacklisted, inbound traffic is throttled or outright rejected, regardless of your sender reputation or message content.

Check your domain’s status across multiple platforms. A single listing can cause widespread delivery failure. Some blocklists operate at scale—Spamhaus, for example, is widely used by ISPs and email providers to filter incoming traffic.

Delisting and Reputational Reset

If you’re listed, follow the delisting process for each platform. Most require a form submission, confirmation of remediation, and proof that the issue is resolved. Spamhaus, for example, requires verification of changes to your email practices before considering removal.

After delisting, avoid sudden spikes in volume from the same IP. Rebuilding reputation takes time. A steady, consistent sending pattern—rather than a burst of messages—is what rebuilds trust with mail providers.

Before you send at scale, verify your domain’s clean status. You can test deliverability in real inboxes with MailTester’s inbox placement tool.

Test your messages in real inboxes before you send.

You’ll find that clean domain status isn’t a one-time checklist. It’s part of ongoing deliverability hygiene. Authentication locks the door. A good reputation gets you past it.

Learn how Spamhaus maintains real-time blocklists. See how Barracuda tracks sender reputation.

How MailTester Helps Verify Your Email Infrastructure

Let’s be clear: setting up SPF, DKIM, and DMARC is just the first step. You still need to know if they’re working in the real world. That’s where MailTester comes in.

Real-World Inbox Placement Testing

MailTester doesn’t just scan your DNS records. It sends test emails through real infrastructure to Gmail, Outlook, and Yahoo — the major inboxes where your campaigns actually land. You get a live verdict: is your message in the inbox, spam folder, or blocked entirely? This is more than a syntax check. It validates your full delivery stack, including authentication, sender reputation, and content filtering. A single misconfigured record or a weak reputation can sink a whole campaign — and MailTester helps catch it before you send.

Pinpointing Delivery Failures with 98.9% Accuracy

With 98.9% accuracy, MailTester identifies whether a domain fails due to authentication (SPF/DKIM/DMARC misconfiguration), policy blocks (like greylisting or volume throttling), or reputation issues (historical spam flags, blacklists). It returns clear insights: "Invalid email" means the address doesn’t exist. "Catch-all" means you’re accepting mail for nonexistent addresses — a red flag for senders. "Risky" flags domains with poor sender history or unstable infrastructure. You get diagnostics, not just a pass/fail. You’re not guessing. You know exactly why a domain fails, and you can act. Use the verification API to audit your sender health automatically before major campaigns or list uploads. Hook it into your workflow, check sender records in bulk, and surface issues before they impact deliverability. If you’re building or cleaning a list, bulk verification runs the same inbox placement tests at scale, keeping your data clean and compliant. The underlying standards — SPF, DKIM, DMARC — are defined in RFCs like RFC 7208 and RFC 6376. These are industry-standard protections, but they only matter if they’re implemented correctly **and** accepted by receiving mail servers. MailTester doesn’t just verify the setup — it tests whether the setup actually delivers. That’s the difference between theory and results. In short: you can get SPF right, but if your domain has a poor reputation, your emails won’t land. MailTester checks both.

Conclusion: Authentication Is the Foundation of Deliverability

SPF, DKIM, and DMARC aren't optional add-ons. They are the technical baseline that tells receivers your email is legitimate.

Properly configured, they reduce hard bounces, defend against spoofing, and improve inbox placement. Ignoring them means sending into a hostile environment without defenses.

Next steps

• Confirm your SPF record includes only authorized senders.
• Ensure DKIM signatures are correctly applied and published.
• Set DMARC to 'p=none' initially, then shift to 'p=quarantine' or 'p=reject' as metrics stabilize.
• Pair this with regular list cleaning and sender reputation monitoring.

Test your setup in real email clients before sending. MailTester simulates inbox delivery across major providers so you can verify your authentication holds up under real-world conditions.

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Can I use SPF, DKIM, and DMARC with any email service?

Yes, all major senders like SendGrid, Mailchimp, and Amazon SES support them. You must configure them in your domain DNS and sender platform.

What happens if I only set up SPF?

SPF provides limited protection. Without DKIM and DMARC, you may still be blocked by major providers, especially with complex senders or third-party services.

How long does it take for SPF/DKIM/DMARC to work?

DNS changes typically propagate in 5–10 minutes but can take up to 24 hours in rare cases. Tests should be run after full propagation.

What does DMARC’s p=none mean?

It instructs receivers to monitor email alignment but take no action against messages that fail SPF or DKIM. Ideal for initial monitoring.

How do I read a DMARC report?

DMARC reports show which sending IPs passed or failed authentication, and how many emails were delivered or quarantined. Use them to refine your policies.

Can two email services use the same SPF record?

Yes, but only if listed with include statements. Avoid combining multiple SPF records—use one with multiple includes to prevent failures.

Do I need a private key for DKIM?

Yes—your email provider generates the private key, which signs outgoing emails. Never share it. The public key goes in DNS.

Should I include every domain in SPF?

Only include trusted sending services. Overloading SPF with too many includes can cause it to fail. Use mechanisms like SPF alignment and DMARC for broader control.

What if my domain fails DKIM during testing?

Check DNS record spelling, ensure the correct selector and domain are used, and verify your email provider is correctly publishing the public key.

How does MailTester help with email authentication?

It runs inbox-placement tests that verify SPF, DKIM, and DMARC in real email clients, helping you catch issues before sending.

Can DMARC prevent spoofing?

Yes—when properly configured, DMARC enforces actions on unauthenticated messages, stopping spoofed emails that pretend to be from your domain.

Is there a free way to test SPF/DKIM/DMARC?

Yes—tools like MXToolbox and Google’s Email Authentication tools allow free checking, but they don’t validate real inbox delivery like MailTester.