> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lettr.com/llms.txt
> Use this file to discover all available pages before exploring further.
# DMARC Records
> Configure a DMARC policy that tells receiving servers to quarantine or reject emails failing SPF and DKIM, protecting against spoofing
After configuring SPF and DKIM for your [sending domain](/learn/domains/sending-domains) in Lettr, DMARC is the final authentication layer that tells receiving servers what to do when emails fail those checks. Without DMARC, a failed SPF or DKIM check is informational only — the receiving server decides on its own whether to deliver, quarantine, or reject the message. With DMARC, you explicitly instruct receivers to quarantine or reject unauthenticated emails claiming to come from your domain.
## Why DMARC Matters
Without DMARC, attackers can send emails that appear to come from your domain. DMARC:
* **Prevents Spoofing** - Blocks unauthorized senders from using your domain
* **Improves Deliverability** - Authenticated emails are more likely to reach the inbox
* **Provides Visibility** - Reports show who is sending email as your domain
* **Enables BIMI** - Required for displaying your logo in email clients
* **Builds Trust** - Recipients know emails from your domain are legitimate
## How DMARC Works
DMARC works with SPF and DKIM to authenticate emails:
1. Sender sends an email claiming to be from `@yourcompany.com`
2. Receiving server checks SPF (authorized sending servers)
3. Receiving server checks DKIM (cryptographic signature)
4. Receiving server checks DMARC policy for instructions
5. Based on the policy, the email is delivered, quarantined, or rejected
```
┌─────────────┐
Sender ────────────►│ Email Sent │
└──────┬──────┘
│
┌──────▼──────┐
│ SPF Check │
└──────┬──────┘
│
┌──────▼──────┐
│ DKIM Check │
└──────┬──────┘
│
┌──────▼──────┐
│DMARC Policy │
└──────┬──────┘
│
┌────────────┼────────────┐
│ │ │
┌─────▼─────┐ ┌────▼────┐ ┌─────▼─────┐
│ Deliver │ │Quarantine│ │ Reject │
└───────────┘ └──────────┘ └───────────┘
```
## DMARC Policies
DMARC has three policy levels:
| Policy | Action | Use Case |
| -------------- | -------------------------------- | ----------------------------- |
| `p=none` | Monitor only, deliver all emails | Initial setup, gathering data |
| `p=quarantine` | Send failing emails to spam | Transitioning to enforcement |
| `p=reject` | Block failing emails entirely | Full protection |
## Setting Up DMARC
### Basic DMARC Record
Add a TXT record to your domain:
| Field | Value |
| ----- | ------------------------------------------------ |
| Type | TXT |
| Name | `_dmarc` |
| Value | `v=DMARC1; p=none; rua=mailto:dmarc@example.com` |
### Record Parameters Explained
```
v=DMARC1; # DMARC version (required)
p=none; # Policy: none, quarantine, or reject
rua=mailto:dmarc@example.com; # Aggregate report email address
ruf=mailto:dmarc-forensic@example.com; # Forensic report email (optional)
pct=100; # Percentage of messages to apply policy
adkim=r; # DKIM alignment: r (relaxed) or s (strict)
aspf=r; # SPF alignment: r (relaxed) or s (strict)
sp=none; # Subdomain policy (optional)
```
| Parameter | Required | Description |
| ---------- | -------- | ---------------------------------------------- |
| `v=DMARC1` | Yes | DMARC version identifier |
| `p=` | Yes | Policy for the domain |
| `rua=` | No | Email address for aggregate reports |
| `ruf=` | No | Email address for forensic reports |
| `pct=` | No | Percentage of messages to apply policy (1-100) |
| `adkim=` | No | DKIM alignment mode (r=relaxed, s=strict) |
| `aspf=` | No | SPF alignment mode (r=relaxed, s=strict) |
| `sp=` | No | Policy for subdomains |
## Recommended DMARC Rollout
A gradual rollout minimizes the risk of blocking legitimate emails:
Start with `p=none` to receive reports without affecting email delivery.
```
v=DMARC1; p=none; rua=mailto:dmarc@example.com
```
Review reports to identify all legitimate email sources.
Move to `p=quarantine` with a low percentage to test enforcement.
```
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com
```
This applies quarantine to only 10% of failing messages.
Gradually increase the percentage as you confirm legitimate emails pass.
```
v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@example.com
```
Then:
```
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com
```
Once confident, switch to `p=reject` for full protection.
```
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
```
Don't jump straight to `p=reject`. Start with `p=none` and monitor reports first. Moving too quickly can block legitimate emails.
## DMARC Alignment with Lettr
When you verify a sending domain in Lettr, the SPF and DKIM records are configured to pass DMARC alignment automatically. Here's how Lettr's infrastructure interacts with each check:
### DKIM Alignment
* Lettr signs every email with a DKIM key specific to your domain
* The `d=` parameter in the DKIM signature matches your sending domain (e.g., `d=yourcompany.com`)
* Supports both relaxed and strict alignment — relaxed allows subdomains to match (e.g., `mail.yourcompany.com` aligns with `yourcompany.com`)
### SPF Alignment
* Lettr uses a return-path domain (configured via the bounce CNAME record) that aligns with your sending domain
* This means the envelope sender domain matches your From domain for SPF alignment
* Supports both relaxed and strict alignment
### What This Means for Your DMARC Policy
Because Lettr handles DKIM signing and SPF return-path alignment for you, emails sent through Lettr will pass DMARC as long as:
1. Your sending domain is **verified** in Lettr (SPF and DKIM DNS records are in place)
2. Your DMARC record exists at `_dmarc.yourdomain.com`
If you also send email from other services (marketing platforms, CRM tools, help desks), make sure those services are also configured for DMARC alignment. A `p=reject` policy will block emails from any source that fails authentication — not just Lettr.
Use `p=none` with aggregate reporting first to verify that all your email sources pass DMARC before moving to enforcement. The DMARC reports will show you exactly which services are passing and failing.
## Check DMARC Status
### Via Dashboard
1. Go to **Domains** → **Sending**
2. Select your domain
3. View the DMARC status indicator
### Via API
```bash theme={null}
curl https://app.lettr.com/api/domains/example.com \
-H "Authorization: Bearer lttr_xxxxxxxxxxxx"
```
```json theme={null}
{
"message": "Domain retrieved successfully.",
"data": {
"domain": "example.com",
"dmarc_status": "valid"
}
}
```
### DMARC Status Values
| Status | Description |
| ---------------- | --------------------------------------------- |
| `valid` | DMARC record found and valid |
| `unverified` | Record not yet detected |
| `invalid` | DMARC record has syntax errors |
| `missing` | No DMARC record found |
| `not_applicable` | DMARC check not required for this domain type |
## DMARC Reports
DMARC reports provide visibility into email authentication:
### Aggregate Reports (RUA)
Daily XML reports containing:
* Source IPs sending email as your domain
* Authentication results (SPF, DKIM pass/fail)
* Policy applied (none, quarantine, reject)
* Volume of emails from each source
Example aggregate report summary:
| Source IP | Messages | SPF | DKIM | Policy Applied |
| --------- | -------- | ---- | ---- | -------------- |
| 192.0.2.1 | 1,500 | Pass | Pass | None |
| 192.0.2.2 | 50 | Fail | Fail | Quarantine |
| 192.0.2.3 | 10 | Fail | Fail | Reject |
### Forensic Reports (RUF)
Individual failure reports containing:
* Original email headers
* Authentication failure details
* Timestamp and recipient information
Forensic reports may contain sensitive information. Many receivers don't send them due to privacy concerns.
### Report Analysis Tools
Raw DMARC reports are XML files that can be difficult to read. Consider using:
* **DMARC Analyzer** - Parses and visualizes reports
* **Postmark DMARC** - Free weekly DMARC digests
* **Valimail** - Enterprise DMARC management
* **dmarcian** - DMARC monitoring and analysis
## Subdomain Policies
Control how DMARC applies to subdomains:
### Inherit Parent Policy (Default)
Subdomains inherit the parent domain's policy:
```
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
```
This applies `p=reject` to `example.com` and all subdomains.
### Explicit Subdomain Policy
Set a different policy for subdomains using `sp=`:
```
v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com
```
This applies `p=reject` to `example.com` but only `p=quarantine` to subdomains.
### Subdomain-Specific Records
Create a separate DMARC record for a subdomain:
```
# At _dmarc.example.com
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
# At _dmarc.mail.example.com
v=DMARC1; p=none; rua=mailto:dmarc@example.com
```
## Common DMARC Configurations
### Monitoring Only
Best for initial setup:
```
v=DMARC1; p=none; rua=mailto:dmarc@example.com
```
### Standard Protection
Good balance of security and flexibility:
```
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com
```
### Maximum Protection
For domains with full authentication:
```
v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.com
```
### BIMI-Ready
Required for BIMI logo display:
```
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@example.com
```
## Troubleshooting
DMARC requires **alignment** between the From address and SPF/DKIM domains:
* Ensure DKIM signature domain (`d=`) matches the From domain
* Ensure return-path domain matches the From domain (or subdomain with relaxed alignment)
* Check alignment mode (`adkim` and `aspf` parameters)
* Verify the `rua` email address is correct
* Check spam folder for reports
* Allow time for reports to arrive (they are sent daily)
* Ensure the receiving mailbox can accept XML attachments
* Some receivers don't send reports for low-volume domains
* Review DMARC reports to identify the failing source
* Ensure all sending services are configured with proper SPF/DKIM
* Consider lowering `pct` temporarily
* Use `p=quarantine` instead of `p=reject` while investigating
* Verify the TXT record is at `_dmarc.example.com`
* Check for typos in the record name
* Allow time for DNS propagation
* Use a DNS lookup tool to verify the record exists
For services that send email on your behalf:
* Add them to your SPF record
* Configure DKIM signing with your domain
* Or use a subdomain with a separate DMARC policy
## Best Practices
1. **Start with `p=none`** - Always monitor before enforcing
2. **Review reports regularly** - Identify legitimate senders before they're blocked
3. **Use aggregate reports** - They're more useful and widely sent than forensic reports
4. **Increase enforcement gradually** - Use the `pct` parameter to phase in policies
5. **Configure all senders first** - Ensure SPF and DKIM are set up for all email sources
6. **Don't forget subdomains** - Set explicit subdomain policies if needed
7. **Consider strict alignment** - Use `adkim=s; aspf=s` for maximum security
## Related Topics
Configure SPF and DKIM
Display your logo (requires DMARC)
Email deliverability best practices
Email security best practices