The DNS records we generate
A plain-language guide to the four records EmailFig gives you to publish: DKIM, the two MAIL FROM records, and DMARC.
When you add a sending domain, EmailFig gives you four DNS records to publish: a DKIM key, a MAIL FROM MX record, a MAIL FROM SPF record, and a DMARC policy. You don’t need to understand them to add a domain; just copy each one across exactly as shown. This page is for when you want to know what each is doing. All four must verify before the domain can send, and together they tell a receiving inbox your mail is genuine rather than spoofed.
DKIM: proves the message wasn’t tampered with
Type: TXT, at a host like efig._domainkey under your domain.
DKIM (DomainKeys Identified Mail) lets a receiving server confirm a message was signed by whoever controls the sending domain, and that nothing in it changed in transit. EmailFig generates a key pair: the DNS record publishes the public half, and EmailFig keeps the private half and signs every message with it.
This is “bring your own DKIM”: the key is generated once and stays the same even if EmailFig later changes which infrastructure sends your mail. Your DNS record never has to change.
MAIL FROM: two records, one job
Type: MX and TXT, both at a subdomain like efig-mail.mail.yourdomain.com.
A custom MAIL FROM domain puts your own domain into the technical “envelope sender” (the Return-Path, distinct from the From address your recipient sees), which is what lets your domain’s own SPF record authenticate the message.
- MX record: tells other servers where to deliver bounce notifications for your custom MAIL FROM address. It points at Amazon SES’s bounce-handling servers (EmailFig sends through Amazon SES); this is the one record that names the underlying infrastructure, because SES requires it to route bounces. It’s DNS-only and never appears in the email.
- SPF (TXT) record: authorises EmailFig’s sending infrastructure to send mail claiming that MAIL FROM subdomain. Without it, mail sent as your MAIL FROM subdomain fails SPF, which also breaks DMARC alignment (below).
The SPF record is only ever published at the MAIL FROM subdomain, never at your domain’s root.
DMARC: tells receivers what to do
Type: TXT, at _dmarc, but published at your domain’s registrable (organisation) domain, not the sending subdomain. If you added mail.acme.com, the DMARC record goes on acme.com, and the records table tells you so on that row.
DMARC builds on SPF and DKIM: it tells receiving servers what to do with a message that fails both, and lets domain owners request aggregate reports. The record EmailFig generates sets a monitor-only policy (p=none).
EmailFig checks for any syntactically valid DMARC record at that domain, not an exact match. So if your organisation already publishes a stricter DMARC policy at the apex domain, you don’t need to add anything: your sending subdomain inherits it, and adding a separate _dmarc record on the subdomain would override (and typically weaken) that policy.
Why all four, together
A domain verifies only once every required record passes. Publishing only the MX record isn’t enough, because SPF is checked on its own. Mail authenticated on every axis is far less likely to land in spam, and is what Gmail and Yahoo’s bulk-sender rules expect. See Meet Gmail and Yahoo bulk sender requirements.
A fifth record type, a tracking CNAME, is reserved for a future per-domain tracking hostname, but it isn’t generated or required today: every account’s tracked links currently share EmailFig’s own tracking domain.