Sender verification
Anyone can put your domain in the From: line of an email. Three
mechanisms in DNS decide whether a receiving server believes it: SPF,
DKIM, and DMARC.
In Elpan you don't write these records. You choose policies in your mail settings, and the panel publishes and maintains the records for them.
The three mechanisms
| The question it answers | Default here | |
|---|---|---|
| SPF | Which servers can send mail for this domain? | softfail. A receiver treats mail from a server not in the list with suspicion but doesn't refuse it. A safe default while a third-party sender can still exist. |
| DKIM | Did this domain really send the message, unchanged? | Active. The panel signs your outgoing mail with a key it generates and holds, and publishes the public half in DNS. Rotate the keys from the mail settings; DNS follows. |
| DMARC | What should a receiver do with mail that fails the other two? | reject. DMARC also makes the other checks effective, because it requires the authenticated domain to align with the From: address the reader sees. |
Why reject is the default
Under a DMARC policy of none or quarantine, forged mail claiming to
come from you still reaches an inbox or a spam folder, and large providers
trust a domain with no firm policy less and less.
The panel controls the whole sending path: it signs your outgoing mail and sends it from the servers SPF lists. Your legitimate mail passes authentication, so a weaker policy gains you nothing, and reject protects your recipients and your domain's reputation.
A newsletter service, a CRM, or an old server can send mail as your domain. Under a reject policy, that mail bounces unless you authorize it.
The right fix is to authorize it. Most services give you a DKIM key or an SPF include to add, and a custom DNS record works well beside the managed ones. Or route the service through an outgoing gateway, a mail service setting that replaces the published SPF and DKIM records with the gateway's.
The wrong fix is to weaken DMARC. Then anyone can forge your domain.
Add an SPF record
The service that sends mail for you tells you what to authorize: usually
an include: pointing at their own record, or an ip4: or ip6:
address, an a: or mx: reference, or a bare a or mx. SPF calls
these mechanisms, and they all go in the same place.
Publish them as a TXT record on the DNS Records page: choose the zone, press Add DNS Record, select TXT, and give it a Value, a complete SPF record listing only what you add:
v=spf1 include:spf.example.net ~all
v=spf1 ip4:192.0.2.25 ip6:2001:db8::25 ~all
Name decides which sending domain the authorization applies to:
- Leave it empty for the domain itself.
- Type the subdomain, e.g.
newsletter, when only the mail fromnewsletter.example.comcomes from that sender.
A receiver checks SPF against the exact domain in the envelope sender. A
record on the parent doesn't cover a subdomain, and a record on a
subdomain doesn't cover the parent. Where a subdomain sends no mail of its
own, publish an explicit v=spf1 -all on it.
When the name already has a generated record, the panel merges your custom SPF record into one published record. Your mechanisms join the managed ones; they don't replace them.
Where several senders share one name, list them in one record or add one record per sender. The merged result is the same.
Once the record is live, the SPF Check action on its row analyzes what is really published for that name, merged result included. How the panel publishes your SPF record covers each step between your record and the published one.
SPF allows at most ten DNS lookups per evaluation. include:, a, and
mx each use at least one; ip4: and ip6: use none.
A name that collects senders can pass the limit silently and then fail everywhere. Above the limit, the panel resolves the senders for you and publishes their addresses (see How the panel publishes your SPF record), but removing entries you no longer use is still better.
Add a DKIM key from a third party
DKIM publishes a key under a selector, at
<selector>._domainkey.<domain>. The sender tells you the selector and
the public key value.
| What they give you | What to add |
|---|---|
A key value, usually starting with v=DKIM1; k=rsa; p=… | A TXT record with Name <selector>._domainkey and the key as Value. |
| A CNAME to a name they host | A CNAME record instead, with their target in Target. |
In both cases:
- Keep the selector exactly as they give it; their signatures point at it.
- Put the subdomain at the end when the key belongs to one:
<selector>._domainkey.newsletter. - Drop their domain if their instructions include it. Name is relative to the zone.
A selector keeps a third-party key separate from every other, including the panel's, so there's nothing to coordinate: the panel's key stays under its selector, and yours sits beside it.
DKIM only has to match the signature on each message, so a second key never affects the mail you send through Elpan.
Write the sender's name there when you create the record. A DKIM value in particular is unreadable a year later.
Both record types can take some time to propagate. A sender usually offers a "verify" button that confirms they can see the record.
What this means in daily use
- A new mail domain is deliverable from its first message. SPF, DKIM, and DMARC are correct before you send anything.
- If a receiver reports "authentication failed", look at the Email Traffic Log: each delivery record shows its SPF, DKIM, and DMARC results per hop.
- Mail that reaches you through a forwarder, e.g. a mailing list or an alumni address, can fail these same checks though the sender did nothing wrong. See Trusted forwarders.
- A generated TXT record can't be edited by hand; to change it, change the policy. See DNS is managed for you.