Skip to content
mailprompt
Start free trial
FeatureUpdated

Set up a sending domain without DNS guesswork

Domain setup gives Mailprompt permission to send as your brand. You add the domain, publish the DKIM, SPF and DMARC records the product generates, and verify the domain before the first marketing send. The records point at Mailprompt hostnames, so you do not have to expose the underlying sending provider in your DNS.

Key facts

  • Google's email sender guidelines require bulk senders to authenticate with SPF, DKIM and DMARC. Source
  • Yahoo's sender best practices likewise ask bulk senders to authenticate their domains and publish a DMARC policy. Source
  • RFC 7208 limits an SPF evaluation to ten DNS lookups, so every include has a cost. Source
  • DMARC policies move from monitoring to quarantine to reject as the sender gains confidence in the authentication data. Source

What this page covers

Part of the Mailprompt features set, this page describes the domain step that every new account completes before its first marketing send. It covers what the records do, why there are several of them and what to check when verification stalls.

A domain is a permission slip

An email has two identities: the visible From address and the domain that signs the message. Receiving servers look at both. If the signing domain does not authorize the sender, the message can be delivered to spam, rejected or silently filtered. The domain setup is how the owner turns an unknown sender into an authorized one.

The setup is not a formality that can be skipped with a checkbox. A new domain has no sending history, and a domain with a broken record has a bad one. Getting DKIM, SPF and DMARC right before the first campaign is easier than repairing a reputation after a failed launch.

Mailprompt asks for a domain or subdomain, generates the records for that domain and verifies them. The customer publishes the records at their DNS provider. The product never needs the DNS provider's password, and it never asks the customer to point their whole domain at Mailprompt.

The three record families

DKIM is the signature. Mailprompt generates a key pair and gives the customer public keys as DNS records. The private key stays on the sending side. A receiving server uses the public key to check that the message was signed by the domain and that the body was not changed in transit. DKIM survives forwarding better than SPF, which is why it matters for deliverability.

SPF is the list of servers allowed to send for the domain. It is a TXT record starting with v=spf1. The setup adds an include for Mailprompt's sending hostnames. SPF is evaluated by the receiving server against the envelope sender, so a forwarded message can fail SPF even when the original send was legitimate. DKIM and DMARC compensate for that.

DMARC tells the receiving server what to do when a message fails authentication and which address receives reports. It is also a TXT record, at _dmarc.<domain>. A monitoring policy collects data; a quarantine or reject policy starts enforcing. The setup screen explains the current policy and what the next step would change.

Why the records point at Mailprompt

The DKIM records use Mailprompt hostnames, and the SPF include points at a Mailprompt host. The customer does not need to know which infrastructure provider signs or delivers the message, and the records do not have to change when that infrastructure changes.

This is not about hiding a subprocessor. The provider is listed in the data processing agreement and the subprocessor list, which is where a customer's legal team expects to find it. It is about keeping the customer's DNS stable and their setup portable. A domain record that names a vendor directly becomes a migration project when the vendor changes.

The sending domain can be the root domain or a subdomain. A subdomain such as mail.example.com isolates marketing reputation from transactional mail and from the corporate domain. For a store that already sends order confirmations from the root domain, a marketing subdomain is often the lower-risk choice.

Verifying, not assuming

After the records are published, Mailprompt checks them. A record can be missing, present but wrong, or present at the wrong host. The setup screen shows the state per record so the customer knows what to fix.

Verification is a poll, not a one-time form submission. DNS changes propagate at different speeds, and a record that was correct five minutes ago can be edited by someone else. The product rechecks before a send and blocks a marketing send when the domain is not verified. That block is a feature: a send from an unverified domain is a deliverability incident waiting to happen.

If a record stays pending, the usual causes are a missing trailing dot in a fully qualified host, a record published at the wrong name, a proxy setting that hides a DNS record or a second SPF record that conflicts with the first. The setup screen should point at the specific record, not just say “verification failed”.

What to do after verification

Verification is the start of the domain's sending life, not the end. Start with a small volume, watch bounce and complaint rates and keep the DMARC reports flowing. A domain that has never sent marketing mail should not begin with the entire list.

The SPF, DKIM and DMARC guide walks through the Shopify-specific setup in more detail. The approval gate is the next control: an authenticated domain still needs a person to approve the message. The revenue report is what you read after the sends are flowing.

Common mistakes

The most common mistake is publishing a second SPF record instead of merging the include into the existing one. Two SPF records at the same name produce a permanent error, and the domain can fail authentication for every sender.

The second mistake is copying a DKIM record into a TXT record with the wrong name. The selector matters. A key published at default._domainkey is not found when the signer uses a different selector.

The third mistake is treating DMARC as a switch that can be flipped to reject on day one. A reject policy on a domain with unknown senders will reject legitimate mail. Start with monitoring, read the reports, then enforce.

Frequently asked questions

Why does Mailprompt ask for DNS records instead of sending from my main domain automatically?

Because the domain owner has to authorize the sender. DNS is the authorization channel: the DKIM key, the SPF include and the DMARC policy tell receiving servers that Mailprompt is allowed to send for the domain. Sending first and asking later is how a domain gets a reputation problem before the owner has seen a single record.

Do I need to change my existing SPF record?

Usually you add one include to the SPF record you already have. The setup screen shows the exact include and warns when the merged record would exceed the ten-lookup limit. Do not create a second SPF record for the same name; merge the mechanisms into one record instead. If you are unsure, copy the current record before you edit it.

How long does verification take?

It depends on DNS propagation and on the receiving resolver. The product polls the records and shows each one as pending, verified or mismatched. A DKIM record often verifies quickly, while a DMARC record may take longer to appear in aggregate reports. If a record stays pending, check the host name and the record type before changing the value again.

Should DMARC start at p=none?

A monitoring policy is a reasonable first step when the domain already sends mail from several systems. It lets you collect reports without rejecting legitimate mail. Once the reports show that your known senders pass authentication, move to quarantine and then to reject. The right pace depends on what else sends from the domain, not on a fixed calendar.

Does domain setup reveal which email provider Mailprompt uses?

The records you publish point at Mailprompt hostnames, not at the underlying provider. The provider is named in the data processing agreement and the subprocessor list, as data protection rules require, but it is not part of the customer-facing DNS setup. That keeps the setup stable if the sending layer changes later.

Sources