DNS and authentication
SPF, DKIM, DMARC and MX
What EmailPal writes for SPF, dual DKIM, DMARC p=reject and MX, why we re-verify against public resolvers, and what to do when a check fails. This is the primer; the setup walkthrough is the Instantly-titled DNS article.
What each record is for
Inbox providers treat missing authentication as a reason to spam-folder or reject. Authentication is not warmup and it is not list verification. It is the ID check: this mail is from who it claims to be.
| Record | Job | EmailPal default |
|---|---|---|
| MX | Where replies are delivered | Points at EmailPal so mail can land in the unified inbox |
| SPF | Which servers may send for the domain | v=spf1 include:_spf.emailpal.io -all (hard fail) |
| DKIM | Cryptographic signature on the message | Two selectors: rsa._domainkey (RSA-2048) and ed._domainkey (Ed25519) |
| DMARC | What to do if SPF or DKIM fail | p=reject at _dmarc |
Gmail and Yahoo's 2024 bulk-sender rules made this mandatory. Google and Yahoo sender requirements.
The click-by-click setup (including BYO paste rules) lives at How to set up DNS records (MX, SPF, DKIM, DMARC). Longer single-record primers: What is SPF, What is DKIM, What is DMARC.
What EmailPal writes
On domains we control (registered through us, or BYO once you delegate), setup writes the records and then checks them from public resolvers. A green check in the dashboard means the public internet sees the same values we published — not that our nameserver agrees with itself.
Typical shapes (values vary per domain; copy what the dashboard shows):
- SPF on
@:v=spf1 include:_spf.emailpal.io -all - DKIM at
rsa._domainkey(2048-bit) anded._domainkey(Ed25519) - DMARC at
_dmarc:v=DMARC1; p=reject; ... - MX on
@pointing at EmailPal
Exact current values are on the domain's DNS page. Pre-warmed inventory already has them; do not edit.
Why p=reject
p=none is monitoring. p=quarantine asks receivers to be suspicious. p=reject tells them to refuse unauthenticated mail. Cold email from a domain that will not defend its own From: header is easier to spoof and easier to distrust. EmailPal ships reject on purpose. See Why DMARC is p=reject.
p=none "to be safe" on a sending-only domain is not safer. There is no second marketing ESP to discover. It just lets spoofed mail through.
Why two DKIM keys
RSA-2048 is widely understood. Ed25519 is smaller and increasingly expected. Signing with both means a receiver that prefers either still sees a valid signature.
Registrar UIs sometimes wrap the RSA TXT into two records. That breaks DKIM. Paste as one. DKIM not validating.
How to check
- Open DNS or the domain detail page.
- Run a recheck if a record looks stale.
- If you brought your own domain, confirm the nameservers or records at your DNS host match what we asked for.
- Believe 8.8.8.8 / 1.1.1.1, not only the registrar preview.
Failures: DNS verification failed.
FAQs
Can I set DMARC to p=none?
Not on EmailPal-hosted sending. The product is authenticated infrastructure, not a domain we send from with an open policy.
Do I still need this on a pre-warmed inbox?
It is already done. That is part of what you are leasing.
Will adding Google or Microsoft as a second sender break SPF?
SPF has a lookup limit (10). If you send from EmailPal and another ESP on the same domain, you can exceed it. Prefer one sending stack per domain.
Does SPF -all hurt deliverability?
No. It stops other people from sending as you. A soft fail (~all) on a cold-email domain is an invitation to impersonate it.
Instantly / Smartlead says DKIM is missing.
Their domain test looks for *their* selector. If you connected EmailPal as SMTP, the sending domain's DKIM is the one we published, not theirs.
Need More Help?
How to set up DNS records (MX, SPF, DKIM, DMARC), Domains and mailboxes, or open a ticket with the domain name and the record that fails.