---
title: "SPF, DKIM, and DMARC: The Complete Email Authentication Guide"
description: "Master email authentication with this comprehensive guide to SPF, DKIM, and DMARC. Learn what each protocol does, how to set up DNS records, troubleshoot common issues, and improve your email deliverability."
url: https://tajo.io/blog/spf-dkim-dmarc-guide/
markdown: https://tajo.io/blog/spf-dkim-dmarc-guide.md
lang: en-US
author: "Set Noa"
author_url: https://tajo.io/set-noa/
published: 2026-03-08
updated: 2026-05-12
alternates: {bg-BG: /bg/blog/spf-dkim-dmarc-guide.md, cs-CZ: /cz/blog/spf-dkim-dmarc-guide.md, de-DE: /de/blog/spf-dkim-dmarc-guide.md, da-DK: /dk/blog/spf-dkim-dmarc-guide.md, es-ES: /es/blog/spf-dkim-dmarc-guide.md, fr-FR: /fr/blog/spf-dkim-dmarc-guide.md, el-GR: /gr/blog/spf-dkim-dmarc-guide.md, hi-IN: /hi/blog/spf-dkim-dmarc-guide.md, id-ID: /in/blog/spf-dkim-dmarc-guide.md, hr-HR: /hr/blog/spf-dkim-dmarc-guide.md, it-IT: /it/blog/spf-dkim-dmarc-guide.md, ja-JP: /jp/blog/spf-dkim-dmarc-guide.md, ko-KR: /kr/blog/spf-dkim-dmarc-guide.md, ar-SA: /ar/blog/spf-dkim-dmarc-guide.md, nl-NL: /nl/blog/spf-dkim-dmarc-guide.md, pl-PL: /pl/blog/spf-dkim-dmarc-guide.md, ro-RO: /ro/blog/spf-dkim-dmarc-guide.md, ru-RU: /ru/blog/spf-dkim-dmarc-guide.md, sv-SE: /se/blog/spf-dkim-dmarc-guide.md, zh-CN: /zh-cn/blog/spf-dkim-dmarc-guide.md, sl-SI: /sl/blog/spf-dkim-dmarc-guide.md, sr-Latn-RS: /sr/blog/spf-dkim-dmarc-guide.md, th-TH: /th/blog/spf-dkim-dmarc-guide.md, tr-TR: /tr/blog/spf-dkim-dmarc-guide.md, ur-PK: /ur/blog/spf-dkim-dmarc-guide.md, vi-VN: /vi/blog/spf-dkim-dmarc-guide.md, sk-SK: /sk/blog/spf-dkim-dmarc-guide.md}
---

[Email](https://tajo.io/blog/?category=email)

# SPF, DKIM, and DMARC: The Complete Email Authentication Guide

Master email authentication with this comprehensive guide to SPF, DKIM, and DMARC. Learn what each protocol does, how to set up DNS records, troubleshoot common issues, and improve your email deliverability.

SPF DKIM DMARC

What are SPF, DKIM, and DMARC?

SPF lists authorized senders, DKIM signs messages, and DMARC tells receiving servers how to handle failures. Publish all three DNS records, test them, and monitor reports before enforcing a strict policy.

[Learn more](https://tajo.io/blog/spf-dkim-dmarc-guide/#why-email-authentication-matters)

Email authentication is the foundation of reliable email delivery. Without proper SPF, DKIM, and DMARC configuration, your carefully crafted emails may never reach your customers’ inboxes. Instead, they end up in spam folders or get rejected entirely.

This comprehensive guide explains what each email authentication protocol does, provides step-by-step DNS setup instructions, covers troubleshooting common issues, and shows you how to verify your configuration is working correctly.

## Why Email Authentication Matters

Email was designed in an era when security was not a primary concern. The original SMTP protocol has no built-in verification mechanism to confirm that an email actually comes from who it claims to be from. This fundamental weakness enables email spoofing, phishing attacks, and spam.

Email authentication protocols solve this problem by allowing domain owners to specify:

- **Which servers can send email on their behalf** (SPF)
- **Cryptographic proof that messages are genuine and unaltered** (DKIM)
- **What to do with messages that fail authentication** (DMARC)

### The Business Impact of Poor Authentication

Without proper email authentication:

- **Lower deliverability**: Major providers like Gmail, Microsoft, and Yahoo filter unauthenticated emails more aggressively
- **Higher spam rates**: Your legitimate emails compete with spoofed messages using your domain
- **Brand damage**: Phishing attacks impersonating your brand erode customer trust
- **Revenue loss**: Marketing campaigns fail to reach subscribers who signed up to receive them
- **Compliance risks**: Many regulations now require proper email authentication

### The Authentication Triad

SPF, DKIM, and DMARC work together as a complete authentication system:

| Protocol | What It Does | Analogy |
| --- | --- | --- |
| SPF | Lists authorized sending servers | A company letterhead with approved offices |
| DKIM | Cryptographically signs messages | A wax seal proving authenticity |
| DMARC | Sets policy for failures + reporting | Instructions on what to do with suspicious letters |

Each protocol addresses different attack vectors. SPF prevents unauthorized servers from sending as you. DKIM prevents message tampering after sending. DMARC ties them together and provides visibility into authentication results.

## Understanding SPF (Sender Policy Framework)

SPF (Sender Policy Framework) is a DNS-based email authentication method that specifies which mail servers are authorized to send email on behalf of your domain.

### How SPF Works

When an email arrives at a receiving server, that server looks up the sender’s domain SPF record. It then checks whether the IP address that sent the email is listed as authorized. If the IP matches, SPF passes. If not, SPF fails.

**The SPF verification process:**

1. You send an email from your marketing platform
2. The receiving server extracts your domain from the Return-Path (envelope sender)
3. The server queries DNS for your domain’s SPF record
4. It compares the sending IP against your SPF record’s authorized list
5. The server records pass, fail, softfail, or neutral result

### SPF Record Syntax

SPF records are published as TXT records in your domain’s DNS. Here is the basic structure:

```
v=spf1 [mechanisms] [qualifier]all
```

**Version tag:** Always starts with `v=spf1`

**Mechanisms:** Define who can send

| Mechanism | Description | Example |
| --- | --- | --- |
| include: | Trust another domain’s SPF | include:spf.brevo.com |
| ip4: | Authorize specific IPv4 | ip4:192.168.1.1 |
| ip6: | Authorize specific IPv6 | ip6:2001:db8::1 |
| a | Allow domain’s A record IPs | a |
| mx | Allow domain’s mail server IPs | mx |
| ptr | Reverse DNS (deprecated) | ptr:example.com |
| exists: | Conditional check | exists:%{i}.spf.example.com |

**Qualifiers:** Define how to handle matches

| Qualifier | Meaning | Result |
| --- | --- | --- |
| + | Pass (default) | Authorized |
| - | Fail (hard) | Unauthorized, reject |
| ~ | SoftFail | Unauthorized, accept but mark |
| ? | Neutral | No policy |

**The all mechanism:** Applied to anything not matching previous mechanisms

### SPF Record Examples

**Basic setup with one email provider:**

```
v=spf1 include:spf.brevo.com -all
```

This authorizes Brevo to send email for your domain and rejects all other senders.

**Multiple email services:**

```
v=spf1 include:spf.brevo.com include:_spf.google.com include:spf.protection.outlook.com -all
```

This authorizes Brevo, Google Workspace, and Microsoft 365.

**Including your own mail server:**

```
v=spf1 ip4:203.0.113.10 include:spf.brevo.com -all
```

This authorizes a specific IP address (your server) plus Brevo.

**Starting with soft fail while testing:**

```
v=spf1 include:spf.brevo.com ~all
```

Using `~all` instead of `-all` marks failures but does not reject. Useful during initial setup.

### Setting Up SPF Records

**Step 1: Identify your sending sources**

List every service that sends email from your domain:

- Email marketing platforms (Brevo, Mailchimp, etc.)
- Transactional email services
- CRM systems
- Help desk software
- Company email (Google Workspace, Microsoft 365)
- Your own mail servers

**Step 2: Gather SPF include statements**

Each email service provider documents their required SPF include. Common examples:

| Provider | SPF Include |
| --- | --- |
| Brevo | include:spf.brevo.com |
| Google Workspace | include:\_spf.google.com |
| Microsoft 365 | include:spf.protection.outlook.com |
| Amazon SES | include:amazonses.com |
| SendGrid | include:sendgrid.net |
| Mailgun | include:mailgun.org |

**Step 3: Create your SPF record**

Combine all includes into one record:

```
v=spf1 include:spf.brevo.com include:_spf.google.com -all
```

**Step 4: Add the DNS record**

In your DNS management interface:

- Type: TXT
- Host/Name: @ (or leave blank for root domain)
- Value: Your complete SPF record
- TTL: 3600 (or default)

**Step 5: Verify the record**

Use DNS lookup tools to confirm:

```bash
dig TXT yourdomain.com
```

Or use online tools like MXToolbox SPF Lookup.

### SPF Limitations and Best Practices

*SPF hard limits*

**The 10 DNS lookup limit:**

SPF has a maximum of 10 DNS lookups. Each `include:` counts as one lookup, and included records may contain their own includes, counting toward your limit. Exceeding this causes SPF permerror (permanent error), failing all checks.

**Strategies to stay under the limit:**

- Use IP addresses directly when possible (ip4: does not count as a lookup)
- Consolidate services using the same provider
- Use SPF flattening services that convert includes to IP addresses
- Remove unused includes from old services

**Other SPF best practices:**

- Only one SPF record per domain (multiple records cause failures)
- Start with `~all` (softfail) during setup, move to `-all` once confirmed
- Update SPF when changing email providers
- Do not use the deprecated `ptr` mechanism
- Keep records as simple as possible

### Common SPF Mistakes

**Multiple SPF records:**

```
Wrong:
v=spf1 include:spf.brevo.com -all
v=spf1 include:_spf.google.com -all

Correct:
v=spf1 include:spf.brevo.com include:_spf.google.com -all
```

**Exceeding DNS lookup limit:**

If you have many includes, check your total lookup count. Use SPF analyzers to verify you are under 10.

**Forgetting to update after changing providers:**

When switching from one email service to another, remove the old include and add the new one.

**Using +all:**

Never use `+all` as it authorizes everyone to send as your domain.

## Understanding DKIM (DomainKeys Identified Mail)

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to your emails, proving the message originated from your domain and was not modified in transit.

### How DKIM Works

DKIM uses public-key cryptography:

1. Your email provider generates a public/private key pair
2. You publish the public key in DNS
3. The provider signs outgoing emails with the private key
4. Receiving servers retrieve your public key from DNS
5. They use the public key to verify the signature
6. A valid signature proves authenticity and integrity

**What DKIM signs:**

DKIM signatures typically cover specific headers and the message body:

- From header (required)
- Subject header
- Date header
- Message body
- Other headers as configured

This prevents attackers from modifying these elements after sending.

### DKIM Record Structure

DKIM records are published as TXT records with a specific naming format:

```
selector._domainkey.yourdomain.com
```

The **selector** is a unique identifier that allows you to have multiple DKIM keys. Different email services use different selectors (e.g., brevo, google, s1, s2).

**DKIM record content:**

```
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...
```

| Tag | Description | Example |
| --- | --- | --- |
| v= | Version (always DKIM1) | v=DKIM1 |
| k= | Key type (usually rsa) | k=rsa |
| p= | Public key (base64) | p=MIGfMA0… |
| t= | Flags (optional) | t=s (strict mode) |
| h= | Hash algorithms (optional) | h=sha256 |

### Setting Up DKIM

**Step 1: Generate DKIM keys**

Your email service provider typically generates keys for you. In Brevo:

1. Go to Settings > Senders, Domains & Dedicated IPs
2. Select your domain
3. Navigate to the DKIM section
4. Copy the provided DNS record

For self-hosted mail servers, generate keys using OpenSSL:

```bash
openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.key
```

**Step 2: Add DKIM DNS record**

In your DNS management:

- Type: TXT
- Host/Name: selector.\_domainkey (e.g., brevo.\_domainkey)
- Value: The DKIM record from your provider
- TTL: 3600

**Step 3: Enable DKIM signing**

In your email provider’s settings, enable DKIM signing for your domain. This tells the provider to sign outgoing messages.

**Step 4: Verify the setup**

Send a test email and check the headers for DKIM-Signature. Use tools like:

- mail-tester.com
- DKIM Validator
- MXToolbox DKIM Lookup

### DKIM Best Practices

**Use 2048-bit keys:**

Older 1024-bit keys are considered weak. Modern security standards recommend 2048-bit RSA keys minimum.

**Rotate keys periodically:**

While not strictly required, rotating DKIM keys annually is good security practice. Add the new key before removing the old one to avoid gaps.

**Monitor for key compromise:**

If your private key is compromised, attackers can sign messages as you. Monitor for unusual authentication patterns.

**Use different selectors for different services:**

Each email provider should use a unique selector. This allows independent key management and does not conflict with other services.

**Check DNS propagation:**

DKIM keys can be long. Ensure your DNS provider supports TXT records of sufficient length. Some providers require splitting the key into multiple strings.

### Reading DKIM Headers

When you receive an email, the DKIM-Signature header shows:

```
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=brevo;
  h=from:to:subject:date:message-id;
  bh=base64hashofbody;
  b=base64signature;
```

| Tag | Meaning |
| --- | --- |
| v= | Version (always 1) |
| a= | Algorithm (rsa-sha256 recommended) |
| c= | Canonicalization (relaxed allows minor changes) |
| d= | Signing domain |
| s= | Selector |
| h= | Signed headers |
| bh= | Body hash |
| b= | Signature |

## Understanding DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC builds on SPF and DKIM to provide policy enforcement and reporting. It tells receiving servers what to do when authentication fails and sends you reports about authentication results.

### How DMARC Works

DMARC adds two critical capabilities:

1. **Policy enforcement**: Define how receivers should handle authentication failures
2. **Reporting**: Receive data about who is sending email using your domain

**DMARC verification process:**

1. A receiving server gets an email claiming to be from your domain
2. It checks SPF (does the sending IP match?)
3. It checks DKIM (is the signature valid?)
4. It checks DMARC alignment (do the authenticated domains match the From header?)
5. If alignment fails, it applies your DMARC policy
6. It sends you aggregate and/or forensic reports

*How DMARC decides what happens to a message*

### DMARC Alignment

DMARC requires **alignment** between the domain in the From header and the domains that pass SPF or DKIM:

**SPF Alignment:** The domain in the Return-Path (envelope sender) must match or be a subdomain of the From header domain.

**DKIM Alignment:** The domain in the DKIM signature (d= tag) must match or be a subdomain of the From header domain.

**Alignment modes:**

| Mode | Description |
| --- | --- |
| Strict (s) | Exact domain match required |
| Relaxed (r) | Subdomains allowed (default) |

With relaxed alignment, if your From header shows `marketing@example.com` and DKIM signs with `brevo.example.com`, alignment passes because both share the `example.com` organizational domain.

### DMARC Record Syntax

DMARC records are published as TXT records at `_dmarc.yourdomain.com`:

```
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100
```

**Required tags:**

| Tag | Description | Values |
| --- | --- | --- |
| v= | Version | DMARC1 (always) |
| p= | Policy | none, quarantine, reject |

**Optional tags:**

| Tag | Description | Default |
| --- | --- | --- |
| rua= | Aggregate report address | none |
| ruf= | Forensic report address | none |
| pct= | Percentage to apply policy | 100 |
| sp= | Subdomain policy | same as p= |
| adkim= | DKIM alignment mode | r (relaxed) |
| aspf= | SPF alignment mode | r (relaxed) |
| fo= | Forensic report options | 0 |
| ri= | Report interval (seconds) | 86400 |

### DMARC Policies Explained

**p=none (Monitor only):**

No action taken on failures. Emails are delivered normally. Use this while analyzing reports and fixing authentication issues.

```
v=DMARC1; p=none; rua=mailto:dmarc@example.com
```

**p=quarantine (Spam folder):**

Failed emails are sent to spam/junk folder. A good intermediate step before full rejection.

```
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100
```

**p=reject (Block):**

Failed emails are rejected entirely. Maximum protection but ensure all legitimate sources pass first.

```
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100
```

### Setting Up DMARC

**Step 1: Ensure SPF and DKIM are working**

DMARC depends on SPF and DKIM. Verify both are correctly configured before adding DMARC.

**Step 2: Start with monitoring (p=none)**

Begin with the most permissive policy to collect data without affecting delivery:

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

**Step 3: Add the DNS record**

In your DNS management:

- Type: TXT
- Host/Name: \_dmarc
- Value: Your DMARC record
- TTL: 3600

**Step 4: Analyze reports for 2-4 weeks**

DMARC aggregate reports arrive daily as XML files. They show:

- Which IPs sent email using your domain
- SPF and DKIM pass/fail rates
- DMARC alignment results
- Receiving server actions

Use DMARC report analyzers to visualize this data:

- DMARC Analyzer
- Postmark DMARC
- Valimail
- dmarcian

**Step 5: Fix authentication issues**

Common issues revealed by reports:

- Legitimate services missing from SPF
- DKIM not enabled for a sending service
- Third-party services sending without proper authentication
- Forwarding breaking SPF alignment

**Step 6: Gradually enforce**

Once legitimate sources pass consistently:

1. Move to `p=quarantine; pct=10` (quarantine 10% of failures)
2. Increase pct to 25, 50, 75, 100
3. Move to `p=reject; pct=10`
4. Increase to full rejection

**Step 7: Maintain and monitor**

Continue reviewing reports. New sending sources, provider changes, or configuration drift can cause authentication failures.

*DMARC rollout from p=none to full rejection*

### Understanding DMARC Reports

**Aggregate reports (rua):**

Daily XML summaries showing:

- Reporting organization
- Date range
- Your published policy
- Authentication results by source IP
- Volume of emails

Example excerpt:

```xml
<record>
  <source_ip>203.0.113.10</source_ip>
  <count>1250</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>pass</dkim>
    <spf>pass</spf>
  </policy_evaluated>
</record>
```

**Forensic reports (ruf):**

Individual message details for failures. More detailed but privacy-sensitive. Many receivers do not send forensic reports.

### DMARC Best Practices

**Always start with p=none:**

Jumping directly to reject can block legitimate email. Monitor first.

**Use a dedicated email address for reports:**

DMARC reports can be voluminous. Use a dedicated address or third-party service.

**Set subdomain policy (sp=):**

If you do not send email from subdomains, set `sp=reject` to protect them from spoofing.

**Use percentage (pct=) for gradual rollout:**

The pct tag lets you enforce policy on a percentage of failures while monitoring the rest.

**Consider dedicated DMARC services:**

For large organizations, services like Valimail, dmarcian, or Postmark DMARC provide better report analysis than raw XML files.

## DNS Record Setup: Complete Walkthrough

Setting up email authentication requires adding specific DNS records. This section provides a complete walkthrough for major DNS providers.

### Gathering Your Required Values

Before starting, collect these values from your email providers:

**For SPF:**

- All include statements (e.g., include:spf.brevo.com)
- Any specific IP addresses you need to authorize

**For DKIM:**

- The selector name (e.g., brevo, google, s1)
- The full DKIM key value

**For DMARC:**

- Your reporting email address

### Adding Records in Common DNS Providers

**Cloudflare:**

1. Log in to Cloudflare Dashboard
2. Select your domain
3. Go to DNS > Records
4. Click Add Record
5. For SPF: Type=TXT, Name=@, Content=your SPF record
6. For DKIM: Type=TXT, Name=selector.\_domainkey, Content=DKIM key
7. For DMARC: Type=TXT, Name=\_dmarc, Content=DMARC record
8. Click Save

**Google Domains/Squarespace:**

1. Go to DNS settings for your domain
2. Scroll to Custom Records
3. Click Manage Custom Records
4. Add each record with appropriate type, host, and data
5. For SPF: Host=@, Type=TXT, Data=SPF record
6. For DKIM: Host=selector.\_domainkey, Type=TXT, Data=DKIM key
7. For DMARC: Host=\_dmarc, Type=TXT, Data=DMARC record

**GoDaddy:**

1. Go to My Products > Domains
2. Click DNS next to your domain
3. Scroll to Records section
4. Click Add for each new record
5. Select TXT for Type
6. Enter the Name (@ for SPF, selector.\_domainkey for DKIM, \_dmarc for DMARC)
7. Enter the Value
8. Save

**Namecheap:**

1. Go to Domain List > Manage
2. Click Advanced DNS
3. Add New Record for each
4. Select TXT Record
5. Host: @ for SPF, selector.\_domainkey for DKIM, \_dmarc for DMARC
6. Value: Your record content
7. Save All Changes

### DNS Propagation

After adding records, changes take time to propagate globally. This typically takes:

- 5-30 minutes for initial visibility
- Up to 48 hours for full global propagation

Use dig or nslookup to verify:

```bash
dig TXT yourdomain.com
dig TXT selector._domainkey.yourdomain.com
dig TXT _dmarc.yourdomain.com
```

Or use online tools like whatsmydns.net to check propagation worldwide.

### Example Complete Setup

For a domain using Brevo and Google Workspace:

**SPF record (TXT at @):**

```
v=spf1 include:spf.brevo.com include:_spf.google.com -all
```

**DKIM record for Brevo (TXT at brevo.\_domainkey):**

```
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA... [key from Brevo dashboard]
```

**DKIM record for Google (TXT at google.\_domainkey):**

```
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BA... [key from Google Admin]
```

**DMARC record (TXT at \_dmarc):**

```
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
```

## Troubleshooting Common Issues

Even with careful setup, email authentication can fail. Here are common issues and how to resolve them.

### SPF Troubleshooting

**SPF record not found:**

Symptoms: SPF checks show “none” or “no record”

Causes:

- Record not added to DNS
- Record added to wrong location (subdomain instead of root)
- DNS propagation not complete

Solutions:

- Verify record exists with `dig TXT yourdomain.com`
- Check the Name/Host field (should be @ or blank for root domain)
- Wait for DNS propagation (up to 48 hours)

**SPF PermError (too many lookups):**

Symptoms: SPF results show “permerror”

Causes:

- More than 10 DNS lookups in your SPF record
- Includes containing excessive nested includes

Solutions:

- Audit your includes and remove unused ones
- Replace includes with ip4: entries where possible
- Use SPF flattening services
- Consolidate services on fewer providers

**SPF SoftFail or Fail for legitimate mail:**

Symptoms: Legitimate emails failing SPF

Causes:

- Sending service not included in SPF
- Sending from an IP not authorized
- Using a relay that changes the envelope sender

Solutions:

- Add the missing include for your sending service
- Check which IP actually sent the email (from headers)
- Contact your email provider for correct SPF settings

**Multiple SPF records:**

Symptoms: SPF shows permerror or random failures

Causes:

- Two or more TXT records containing v=spf1

Solutions:

- Combine all mechanisms into a single SPF record
- Delete duplicate SPF records

### DKIM Troubleshooting

**DKIM signature missing:**

Symptoms: No DKIM-Signature header in emails

Causes:

- DKIM signing not enabled in email provider
- Domain verification not completed
- Sending through non-DKIM path

Solutions:

- Enable DKIM in your provider’s settings
- Complete domain verification steps
- Check provider documentation for DKIM setup

**DKIM verification failed:**

Symptoms: DKIM shows “fail” in authentication results

Causes:

- DNS record not published or incorrect
- Wrong selector used
- Key mismatch between DNS and signing
- Message modified in transit

Solutions:

- Verify DNS record exists at selector.\_domainkey.domain
- Compare selector in DKIM-Signature header with DNS
- Regenerate keys if mismatch suspected
- Check for mail filters or relays modifying messages

**DKIM key too long for DNS:**

Symptoms: Cannot save DKIM record, truncation errors

Causes:

- 2048-bit keys exceed single TXT record length
- DNS provider has character limits

Solutions:

- Split the key into multiple quoted strings (most providers handle this automatically)
- Check if your DNS provider supports long TXT records
- Use 1024-bit keys temporarily (less secure)

Example of split DKIM record:

```
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
"...continuation of key..."
```

### DMARC Troubleshooting

**DMARC alignment failures:**

Symptoms: SPF and DKIM pass but DMARC fails

Causes:

- The authenticated domain does not match the From header domain
- Third-party sending service using their own domain
- Misconfigured envelope sender

Solutions:

- Ensure your email provider signs with your domain (custom DKIM)
- Configure custom Return-Path/envelope sender
- Use relaxed alignment mode (adkim=r; aspf=r)

**Not receiving DMARC reports:**

Symptoms: No aggregate reports arriving

Causes:

- rua address incorrect
- Email address cannot receive external email
- Reports going to spam
- Receiving servers not sending reports

Solutions:

- Verify rua syntax: `rua=mailto:address@domain.com`
- Test that the reporting address can receive external mail
- Check spam folder for reports
- Note: Not all receivers send DMARC reports

**DMARC record not found:**

Symptoms: DMARC checks show “no record”

Causes:

- Record published at wrong location
- Using wrong format (must be TXT at \_dmarc subdomain)

Solutions:

- Record must be at \_dmarc.yourdomain.com
- Verify with `dig TXT _dmarc.yourdomain.com`

### General Troubleshooting Tools

**Online validators:**

- MXToolbox (mxtoolbox.com) - SPF, DKIM, DMARC lookups
- Mail Tester (mail-tester.com) - Send test email for full analysis
- DMARC Analyzer - Report visualization
- Google Admin Toolbox - Check MX, SPF, DKIM

**Command line tools:**

```bash
# Check SPF
dig TXT yourdomain.com

# Check DKIM
dig TXT selector._domainkey.yourdomain.com

# Check DMARC
dig TXT _dmarc.yourdomain.com

# Check from specific DNS server
dig @8.8.8.8 TXT yourdomain.com
```

**Email header analysis:**

Check the Authentication-Results header in received emails:

```
Authentication-Results: mx.google.com;
  dkim=pass header.d=example.com header.s=brevo;
  spf=pass smtp.mailfrom=example.com;
  dmarc=pass action=none header.from=example.com
```

## Email Authentication and Brevo

Brevo provides comprehensive email authentication support, making it straightforward to configure SPF, DKIM, and DMARC for your sending domains.

### Setting Up Authentication in Brevo

**Step 1: Add your domain**

1. Log in to your Brevo account
2. Navigate to Settings > Senders, Domains & Dedicated IPs
3. Click Add a Domain
4. Enter your domain name

**Step 2: Configure SPF**

Brevo provides the SPF include to add to your DNS:

```
include:spf.brevo.com
```

Add this to your existing SPF record or create a new one:

```
v=spf1 include:spf.brevo.com -all
```

**Step 3: Configure DKIM**

Brevo generates DKIM keys automatically. Copy the provided record:

1. Go to your domain settings in Brevo
2. Find the DKIM section
3. Copy the DNS record name and value
4. Add the TXT record to your DNS

**Step 4: Verify configuration**

Brevo automatically checks your DNS records. Green checkmarks indicate successful configuration.

### Benefits of Proper Brevo Authentication

When you properly configure authentication with Brevo:

- **Higher inbox placement**: Gmail, Microsoft, and other providers trust authenticated messages
- **Brand protection**: DMARC prevents spoofing of your domain
- **Better analytics**: Accurate tracking of opens and clicks
- **Reputation building**: Consistent authentication builds sender reputation

## Conclusion

Email authentication through SPF, DKIM, and DMARC is no longer optional for businesses that rely on email communication. These protocols protect your brand from spoofing, improve deliverability, and build the trust necessary for effective email marketing.

**Key takeaways:**

- **SPF** authorizes sending servers through DNS
- **DKIM** proves message authenticity with cryptographic signatures
- **DMARC** enforces policy and provides visibility through reports
- Start with monitoring (p=none) before enforcing rejection
- All legitimate sending sources must be properly configured
- Regular monitoring prevents configuration drift

Your transactional emails reach customers reliably, your marketing campaigns achieve better inbox placement, and your brand remains protected from spoofing attacks.

Ready to improve your email deliverability? Start by auditing your current authentication setup with the tools mentioned in this guide, then systematically configure SPF, DKIM, and DMARC following the step-by-step instructions provided.

## Where Tajo fits

Tajo is the agentic integration builder. Keep your providers. Agents connect everything else, and you approve each sync. Tajo is in early access. [Request early access](https://tajo.io/#early-access)

## Frequently Asked Questions

**What are SPF, DKIM, and DMARC?**

SPF verifies sending servers, DKIM adds a digital signature to emails, and DMARC tells receivers how to handle unauthenticated messages. Together, they authenticate your emails and protect against spoofing.

**Do I need all three (SPF, DKIM, DMARC)?**

Yes. Google and Yahoo now require SPF and DKIM for all senders, and DMARC for those sending over 5,000 emails/day. All three together provide the best deliverability and security.

**How do I set up SPF, DKIM, and DMARC?**

Add DNS records to your domain: SPF as a TXT record listing authorized senders, DKIM as a TXT record with your public key, and DMARC as a TXT record with your policy. Your email platform provides the specific values.

**What is the difference between SPF, DKIM, and DMARC?**

SPF specifies which servers can send email for your domain. DKIM adds a cryptographic signature proving message authenticity. DMARC sets policy for how receivers should handle authentication failures and provides reporting. All three work together for complete email authentication.

**Do I need all three (SPF, DKIM, and DMARC)?**

For optimal deliverability and security, yes. SPF alone is vulnerable to spoofing. DKIM alone does not specify policy. DMARC requires SPF or DKIM to function. Together, they provide comprehensive protection and the best inbox placement rates.

**How long does it take for email authentication to work?**

DNS changes typically propagate within 30 minutes to 48 hours. Once propagated, authentication applies immediately. However, building sender reputation based on consistent authentication takes weeks to months.

**Will setting up DMARC with p=reject block my legitimate emails?**

It can if configured incorrectly. This is why you should always start with p=none (monitoring), analyze reports for 2-4 weeks, fix any issues, then gradually move to quarantine and reject. Never skip the monitoring phase.

**What is SPF alignment vs DKIM alignment?**

Alignment means the authenticated domain matches the visible From header domain. SPF alignment compares the Return-Path domain. DKIM alignment compares the signing domain (d= tag). DMARC requires at least one to align.

**Can I have multiple DKIM keys for one domain?**

Yes. Each email service can use a different selector (e.g., brevo.\_domainkey, google.\_domainkey). This allows multiple services to sign with DKIM independently. There is no limit on the number of DKIM selectors.

**Why do my emails still go to spam after setting up authentication?**

Authentication is necessary but not sufficient for inbox placement. Other factors include sender reputation, content quality, engagement rates, and list hygiene. Authentication gets you past the first filter; good practices determine final placement.

**How do I read DMARC aggregate reports?**

DMARC aggregate reports are XML files. Use tools like dmarcian, Postmark DMARC, or DMARC Analyzer to parse and visualize them. These tools show which IPs send email as your domain and their authentication pass/fail rates.

**What happens if I exceed the SPF 10 lookup limit?**

SPF returns a permanent error (permerror), and all SPF checks fail. To fix this, remove unused includes, replace includes with IP addresses where possible, or use SPF flattening services.

**Should I use -all or ~all in my SPF record?**

Use \`~all\` (softfail) while testing and building confidence. Once you confirm all legitimate sources pass, switch to \`-all\` (hard fail) for stronger protection. Softfail marks failures but does not reject; hard fail authorizes rejection.

**How often should I rotate DKIM keys?**

There is no strict requirement, but annual rotation is a good security practice. When rotating, add the new key first, wait for DNS propagation, enable signing with the new key, then remove the old key after a transition period.

**Do subdomains need separate authentication?**

SPF: Yes, each subdomain needs its own SPF record if sending email from it. DKIM: Keys can be shared or separate per subdomain. DMARC: Subdomains inherit the parent policy unless sp= is set or the subdomain has its own DMARC record.

## Related Articles

### [Email Blacklist Check: Complete Guide to Detection, Removal, and Prevention](https://tajo.io/blog/email-blacklist-check-guide/)

Mar 8, 2026 · 13 min read

5 steps

### [Email Deliverability: Complete Guide to Inbox Placement \[2026\]](https://tajo.io/blog/email-deliverability-complete-guide/)

Mar 8, 2025 · 13 min read

After 60 days inactive → After 90 days inactive

### [What Is an MCP Server? How MCP and MCP UI Work in 2026](https://tajo.io/blog/what-is-an-mcp-server/)

Oct 3, 2026 · 15 min read

Step 1 → Step 6