Go-Live Pre-FlightBeta
Your sandbox tested the message. This tests the domain — before you flip to live sending.
What does a pre-flight check cover that an email sandbox cannot?
A testing sandbox captures your message in a fake inbox so you can inspect it safely. It never delivers, so it never exercises your production domain — which is where going live actually breaks. The two tools answer different questions:
| Question | Answered by |
|---|---|
| Does the message look right — HTML, headers, spam score? | Your testing sandbox |
| Are the DKIM selectors your provider issued actually published, and is the key usable? | This check |
| Can SPF alignment be predicted from this provider's known Return-Path behavior? | This check, when the behavior is documented — otherwise it says so and a real send is required |
| What did a real receiving server actually see? | Only a real send can tell you |
Mailtrap's own setup guidance, for when domain verification stays pending: “use dig, nslookup, or an online DNS lookup to confirm each record is visible publicly” — Mailtrap, setting-up-sending-domain. This is that lookup, done for every record at once — and it parses the DKIM key rather than just confirming something resolves.
Before you flip the switch
Run this check against the records your provider issued. For the wider picture of the domain's authentication posture — every SPF, DKIM and DMARC finding rather than just this provider's records — run a deliverability audit. If you care about key strength and algorithms specifically, a cryptographic posture report inventories DKIM key sizes, DNSSEC, DANE and MTA-STS and exports them as a CycloneDX CBOM.
After you flip it
A pre-flight check reads DNS and predicts; it cannot observe a delivery. Send one message through the inbox reality check to see the real Authentication-Results, including a genuine RFC 6376 DKIM signature verification. Then keep monitoring the domain, because posture drifts the moment someone adds a vendor. When you are ready to tighten DMARC from p=none toward reject, the DMARC policy simulator models the outcome before you publish it.
Go-live pre-flight FAQ
What does a go-live pre-flight check actually test?
It checks that the DNS records your sending provider told you to publish are actually live, correct, and capable of producing a DMARC pass — before you switch from a test sandbox to real sending. That is a different question from whether your email looks right. A sandbox captures the message and inspects its HTML, headers and spam score; none of that touches your production domain's DNS, which is where go-live actually breaks.
Why doesn't my email testing sandbox catch this?
Because a sandbox never delivers. It captures the message in a fake inbox, so there is no real receiver evaluating your production domain, no SPF check against your real sending infrastructure, and no confirmation that the DKIM selector your provider will sign with was ever published. When you flip to live you switch to a code path that was never exercised. That gap is structural, not a gap in any particular sandbox product.
What is SPF alignment, and why can it fail while SPF passes?
DMARC does not ask whether SPF passed. It asks whether the domain SPF authenticated — the Return-Path, or envelope sender — matches the From: address your recipients see. Many providers bounce mail via a subdomain of your domain, which satisfies relaxed alignment (the default) but not strict alignment. So if your DMARC record sets aspf=s, SPF stops counting toward DMARC entirely and you are silently relying on DKIM alone. When a provider's Return-Path behavior is documented in our registry, this check predicts alignment from it; when it is not, the result says alignment is unknown and asks you to confirm with one real send.
Why do you ask me to paste records instead of just knowing them?
Because the important ones are account-specific. SendGrid's Return-Path host contains a per-account token, Amazon SES generates three random DKIM selectors per identity, and Mailtrap's verification host exists only on your dashboard. No registry can predict those, and a tool that guessed them would be confidently wrong. Pasting what your provider actually issued is the only way to verify the real thing. DNS records are public data, so nothing secret is involved.
What does 'unverified' next to a record mean?
It means we have documented that convention but have not confirmed it against live DNS ourselves. Provider conventions drift — hosts get renamed and targets move — so we mark what we have checked and when, rather than presenting every entry with equal confidence. Every provider entry carries the date we last verified it.
Is anything sent to you, and is anything changed?
Nothing is changed: the check is strictly read-only, writes nothing to your DNS, and sends no mail. But be clear on what travels. This runs on our server, not in your browser, so the domain you enter and any records you paste are sent to HireAmino, and the record names are looked up against Cloudflare's DNS-over-HTTPS resolver. When Cloudflare reports a record missing, we ask Google Public DNS for a second opinion before calling it not published — Google receives only that record's name and type, and only in that case. These are the same lookups any mail server makes. We do not store the check or its result, and result pages are not indexed. No credentials, API keys or message content are involved.
It says a record is not visible yet. Does that prove it was never published?
No — and the wording is deliberate. We only report a record as missing when two independent resolvers (Cloudflare and Google Public DNS) both fail to return it. That is strong evidence, but recursive resolvers can hold a cached negative answer for a short while after a record is created, so a record published minutes ago can still show as not visible. If you just created it, wait a little and re-run; if it has been hours, it most likely was never published at your DNS host.
It says my DKIM selector publishes a revoked key. What is that?
An empty p= tag. RFC 6376 defines a DKIM record with an empty public key as revoked — a deliberate 'this selector signs nothing' signal, normal for a retired selector. Tools that treat any record with a p= tag as a working key will report it as healthy. If your provider just issued that selector and it is revoked, the key was never installed on their side.
What should I do after this passes?
Send one real message and read what a receiver actually saw. A pre-flight check reads DNS and predicts; it cannot observe an actual delivery. Our inbox reality check verifies the real Authentication-Results — including a genuine RFC 6376 DKIM signature verification — on a message you send.