Skip to content
mailprompt
Start free trial
HelpUpdated

Add a sending domain and verify it

Add the domain in Settings, then publish the DKIM, SPF, DMARC and return-path records the app generates. DKIM signs each message, SPF lists the servers allowed to send, DMARC tells receivers what to do when both fail, and the return path carries bounces. Sending stays blocked until the required records verify.

Key facts

  • RFC 7208 defines SPF, the DNS record that lists which hosts may send mail for a domain. Source
  • RFC 6376 defines DKIM, which signs a message so a receiver can verify the domain and the body. Source
  • DMARC combines SPF and DKIM alignment with a published policy for messages that fail both. Source
  • Google's sender guidelines ask bulk senders to authenticate with SPF, DKIM and DMARC and to keep alignment with the From domain. Source

What the records are for

This article is part of the Mailprompt help centre. It explains the DNS work behind a sending domain and how to read the states the app shows. The exact values are always the ones generated for your account in the app; the shapes below are there to help you recognise them.

A mailbox provider decides whether to trust a message using several signals. Authentication is the part you control with DNS. DKIM proves the message was authorised by the domain and was not changed in transit. SPF lists the hosts that may send for the domain. DMARC tells the receiver what to do when neither aligns with the From domain, and gives you reports. The return path carries bounces back to the sender infrastructure.

DKIM: signatures and selectors

DKIM uses a selector, which is the label before ._domainkey in the hostname. The app generates a selector and a key pair for your domain, and shows a CNAME record for the public key. The message is signed with the private key; the receiver fetches the public key from DNS and verifies the signature.

Publish every DKIM record the app lists. A domain with two of three records can pass some messages and fail others, which is harder to diagnose than a clean failure. If your DNS provider flattens or proxies CNAMEs, set the record to DNS-only so the receiver sees the real value.

Do not rotate DKIM keys by deleting the old record first. If you need to change keys, publish the new record, wait for it to verify, then sign with the new key. The app keeps the old record visible while the change is in progress for exactly this reason.

SPF: one record, merged includes

SPF is a TXT record at the domain root that starts with v=spf1. It lists the hosts allowed to send, with mechanisms and a final qualifier. Mailprompt provides an include to add to the record you already have.

There must be exactly one SPF record per domain. If your provider already has one, edit it and add the include before the final ~all or -all; do not add a second TXT record. If you have no record, create one with the include and a soft-fail qualifier. A hard fail is a deliberate choice for a mature domain, not a default.

SPF has a lookup limit. Adding many includes can push a record over the limit and produce a permerror even though every host is correct. If you already have several includes, remove one you no longer use before adding another.

DMARC: policy and reporting

DMARC is a TXT record at _dmarc.<domain>. It tells the receiver what to do when a message fails both SPF and DKIM alignment: none only monitors, quarantine sends suspicious mail to spam, and reject refuses it. It also names an address for aggregate reports.

Start with p=none while you confirm that legitimate mail passes. Move to quarantine after a few weeks of clean reports, then to reject when you are confident. A policy that is stricter than your authentication can silently block legitimate mail, including password resets and order confirmations.

If the domain already publishes DMARC, Mailprompt reads the existing record and does not ask for a second one. Two DMARC records at the same name are invalid, and receivers may ignore both.

The return path

The return path, also called the envelope sender or MAIL FROM, is the address that receives bounces. It is a subdomain of your sending domain, with an MX record pointing at the bounce handler and its own SPF record. The MX record must point at a hostname, never at a CNAME.

The return path is what makes bounce handling reliable: a hard bounce goes back to the envelope sender, which is why that address needs to be routable and authenticated. The visible From address stays your domain, so recipients see the brand rather than the bounce subdomain.

Reading the verification states

The domain list shows each record as verified, missing, mismatched or in conflict.

Verified means the value at the hostname matches what the app generated. Missing means no record was found. Mismatched means a record exists but the value differs. Conflict means more than one record of a type exists where only one is valid, or a record points somewhere the app cannot use.

The domain itself has a state. Pending means at least one required record has not verified. Verified means DKIM and SPF pass and the domain can send. A domain can also be paused by the operator for a deliverability or compliance reason; the app shows the reason and the person to contact.

Common problems

A record added to the wrong zone is common when a domain uses a separate DNS host from its registrar. Check the nameservers for the domain, not the registrar's default. A record with the domain appended twice, such as s1._domainkey.example.com.example.com, is a host-field mistake: enter only the part before the domain.

Proxy settings are the other frequent cause. An orange-cloud proxy on a CNAME returns the proxy's address, not the DKIM key. Set authentication records to DNS-only. If the provider does not allow that, use the TXT form of the record when the app offers one.

Before you send

Add the domain before building the first flow if you can. Drafts do not need a verified domain, but approval and sending do. The getting started guide puts the domain step in the right order, and the deliverability guide walks through the same records in a Shopify context.

Frequently asked questions

Why does the app show four record groups?

Each group does a different job. DKIM carries the public keys that verify a signature. SPF lists the sending hosts for the domain. DMARC publishes the policy and the reporting address. The return path, also called MAIL FROM or the envelope sender, receives bounces and carries its own SPF record. All four are needed for a clean setup at volume, and the exact hostnames and values are generated for your account in the app.

Do I need to replace my existing SPF record?

No. A domain must have exactly one SPF record, so merge the new include into the record you already have rather than adding a second TXT record starting with v=spf1. Two SPF records make the result permerror, which is worse than no record. The app notes the include to add and warns when it finds more than one SPF record at the root.

How long does verification take?

A record can verify within minutes, but providers cache DNS and some publish changes slowly. Mailprompt rechecks on a schedule and updates the state, so you do not need to keep pressing a button. If a record stays missing after a few hours, check the hostname for a typo, confirm the record is in the authoritative zone rather than a local override, and check whether the provider appended the domain to the host.

Can I send before DMARC is added?

The app requires DKIM and SPF to pass before sending, because those protect the domain and the message. DMARC is strongly recommended and the app shows it as missing until a policy is published. If the domain already has a DMARC record, Mailprompt reads it instead of asking for a second one. Never publish two DMARC records at the same name.

What does a mismatched record mean?

The hostname exists but the value is not what the app expects. This usually happens after copying a value from an older setup, adding a provider's default record alongside the generated one, or editing a record that the app created. Delete the conflicting value, paste the current value from the app, and wait for the next check. If you use a proxy, make sure the record is DNS-only.

Sources