SPF, DKIM, and DMARC are three DNS records that tell receiving mail servers whether a message claiming to come from your domain is legitimate. Without them, ISPs increasingly send mail to spam or reject it entirely. With them configured correctly, mail lands in the inbox. NimbusOS automates this for every domain purchased through the platform's outbound infrastructure pipeline, but understanding what each record does helps you debug issues and configure domains you already own. This article explains each record in plain terms and walks through the NimbusOS provisioning flow.
The Three Records in Plain English
SPF (Sender Policy Framework)
SPF is a TXT record that lists the IP addresses or service hostnames authorized to send mail for your domain. When a receiving server gets a message claiming to be from sender@yourdomain.com, it looks up the SPF record for yourdomain.com and checks whether the sending IP is listed.
A typical SPF record for a NimbusOS-managed domain looks like:
v=spf1 include:_spf.reachinbox.ai ~all
The include: directive authorizes any IP in ReachInbox's SPF chain. The ~all at the end is a soft fail for anything not authorized; messages still deliver but may land in spam. For strict production domains, use -all to hard-fail unauthorized sends.
SPF is simple in concept, fiddly in practice. Three common issues.
Too many DNS lookups. SPF allows at most 10 include: or a: lookups. Chain too many and the record fails validation. Some tools produce long chains without warning.
Incorrect mechanism. +all authorizes anything as your domain. This is catastrophically wrong; it tells every mail server on the internet that any IP can impersonate you. Never use +all.
Alignment failure. SPF alignment requires the MAIL FROM domain (envelope sender) to match the message's From header domain. Mismatched alignment breaks DMARC even if SPF passes in isolation.
DKIM (DomainKeys Identified Mail)
DKIM adds a cryptographic signature to every outgoing message. The signature is computed from parts of the message content and headers. The receiving server fetches the public key from your DNS and verifies the signature.
A DKIM record is a TXT record at a selector-specific name. For NimbusOS-managed domains a typical entry looks like:
reachinbox._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0..."
The selector (here reachinbox) lets you rotate keys without disrupting in-flight mail. The public key is 2048-bit RSA.
DKIM provides two things SPF does not: content integrity (proof the body was not modified in transit) and identifier alignment independent of the envelope. DMARC treats DKIM-signed messages more kindly than SPF-only.
Common DKIM issues:
Selector name mismatch. The record must be published at the exact selector the sending service uses. Publishing dkim._domainkey when the service signs with selector mail breaks DKIM.
Truncated key. DKIM public keys are long. Some DNS providers truncate at 255 characters. The right pattern is to split into multiple quoted strings within the TXT record.
Missing DKIM on some messages. If only half your mail is DKIM-signed, receivers notice the inconsistency.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
DMARC sits on top of SPF and DKIM. It tells receivers what to do when authentication fails, and it requests reports on authentication outcomes.
A starter DMARC record looks like:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s
The p= directive is the policy. Values:
none: Just monitor. Do nothing to failing mail. This is the right starting point.quarantine: Send failing mail to spam.reject: Bounce failing mail.
The rua= directive requests aggregate reports. Check these reports weekly to see authentication pass rates.
The adkim=s and aspf=s directives require strict alignment. The From header domain must match exactly. s (strict) is stronger than r (relaxed).
Why All Three Matter
SPF alone is fragile. It breaks when mail is forwarded because the forwarding server's IP is different.
DKIM alone allows spoofing by anyone who can write to your DNS for the DKIM selector, which is normally your own admins but can be exploited in managed DNS services.
DMARC unifies them. A DMARC-passing message has valid SPF OR valid DKIM, with alignment, and any failure is reported back to you so you can fix it.
Modern major ISPs (Gmail, Microsoft, Yahoo) require DMARC on all bulk senders as of 2024-2025. Sending significant volume without DMARC is a fast path to spam.
NimbusOS Automatic Provisioning
When you buy a sending domain through /outbound/launch-infrastructure, the pipeline provisions DNS records automatically.
Step 1. Domain purchase through NameSilo.
Step 2. Nameserver change to Cloudflare.
Step 3. Cloudflare zone creation.
Step 4. DNS record provisioning. DNSProvisioningEngine writes SPF, DKIM, DMARC, and MX records for the domain.
Step 5. DNS propagation wait (exponential backoff up to 48 hours).
Step 6. Domain readiness check via check_domain_readiness(domain). This computes a 0-100 score across SPF presence, DKIM presence, DMARC presence, DMARC policy strength, MX validity, and blacklist status. A score of 80 or higher clears for inbox provisioning.
Step 7. Inbox provisioning.
If readiness score stays below 80, the pipeline halts with a specific record-level error. You can fix the record manually in Cloudflare and re-run the check, or (more commonly) the pipeline auto-retries until propagation completes.
Connecting a Domain You Already Own
If you did not buy the domain through NimbusOS, you connect it manually. The Domain Health page at /deliverability/domains lets you add a domain for monitoring and shows a config checklist.
The checklist shows the four records you need, with the exact values for each. Copy and paste into your DNS provider. The platform checks propagation every 15 minutes and flips the status to ready when all records are live.
The DNS provider does not need to be Cloudflare. Route53, Google Cloud DNS, self-managed BIND, and any other provider works. The records are standard.
DMARC Policy Progression
A common DMARC mistake is jumping straight to p=reject. This breaks legitimate mail that fails authentication for benign reasons (forwarded mail, mailing lists, occasional alignment misses).
The right progression is:
Week 1 to 2. p=none. Monitor only. Read the aggregate reports.
Week 3 to 4. If 99 percent of mail is passing, move to p=quarantine with pct=25. This quarantines 25 percent of failing mail. Watch for legitimate mail going to spam.
Week 5 to 6. Increase pct gradually: 50, 75, 100.
Week 7 plus. If quarantine at 100 percent is clean, move to p=reject.
NimbusOS-managed domains start at p=none and can be upgraded from the Domain Health page.
Reading DMARC Aggregate Reports
DMARC aggregate reports arrive daily as XML files. They show, per source (an IP or service), how many messages authenticated, failed, or only partially authenticated.
NimbusOS has a DMARC report parser. Point the rua= address to a NimbusOS-hosted inbox (the DMARC ingestion endpoint) and the platform aggregates reports into a dashboard.
Three things to look for in reports.
Shadow IT senders. A service your team is sending from without authorization. Fix by either adding the service to SPF or stopping the use of your domain.
Alignment-only failures. Where SPF or DKIM passes but does not align. Fix by adjusting the service to use the right envelope sender or DKIM selector.
Forwarding failures. Some mail going to mailing lists or forwarding addresses fails. Hard to fix because the forwarder rewrites the envelope. DMARC ARC is the long-term solution.
BIMI: The Optional Fifth Record
Some brands add BIMI (Brand Indicators for Message Identification). BIMI shows your logo next to authenticated mail in the recipient's inbox, which lifts trust and open rates.
BIMI requires DMARC at p=quarantine or p=reject and a Verified Mark Certificate (VMC) for your logo. The VMC costs around USD 1,500 per year and is issued by a Mark Verifying Authority.
NimbusOS does not auto-configure BIMI because it requires the external certificate. The Domain Health page shows BIMI status if present.
Troubleshooting
"Domain readiness score stuck at 60"
The readiness check scores each record. Open the details; a score of 60 usually means two of the four records are missing or wrong. Check the exact record the check expected against what is published.
"SPF record evaluates as PermError"
Usually too many DNS lookups. Use a SPF flattening service or NimbusOS's spf-flatten utility to collapse the chain.
"DKIM signature present but fails validation"
Either the public key in DNS does not match the private key the service is signing with, or the DNS record is truncated. Verify the full key matches exactly.
"DMARC says pass SPF but fail DKIM on forwarded mail"
Normal. Forwarders break DKIM signatures. SPF usually fails too because the forwarding IP is not in your SPF. ARC (Authenticated Received Chain) is the long-term fix, but most receivers accept SPF alignment from the forwarder side.
"Changed DMARC to p=reject and legitimate mail is bouncing"
Roll back to p=quarantine immediately. Investigate which source is failing. It is almost always a service that is not properly SPF-aligned or DKIM-signed. Fix the service, then escalate back to reject.
Frequently Asked Questions
Do I need a separate DKIM selector per sending service?
Yes. Multiple services signing for the same domain should use different selectors. This lets you revoke a single service without invalidating the others.
Can I use DMARC with a subdomain policy different from the main domain?
Yes. The sp= directive sets the subdomain policy. A common setup is p=reject on the root domain and sp=quarantine on subdomains used for different services.
Does NimbusOS sign its own DMARC reports?
Yes, when the domain is routed through NimbusOS's DMARC ingestion endpoint. The dashboard shows parsed reports and trends.
What happens when my DKIM key rotates?
NimbusOS handles rotation automatically for managed domains. Old keys are retained for 30 days so in-flight mail continues to verify. New mail signs with the new key. DNS is updated to include both keys during the transition window.
What to Read Next
Useful next pages after this one: Deliverability Overview for the NDS score that reads authentication health, ISP Monitoring for how authentication results feed into per-ISP views, and BYOSMTP Configuration if you are running custom SMTP and need to understand authentication on a self-managed domain.