Skip to main content
How ReallyQuickEmails (RQE) authenticates your sends and what’s behind “does it reach the inbox?”. This isn’t a step-by-step tutorial (for that, see Domains), but the theory to diagnose problems and decide what to configure.

​
The authentication stack

When a mail server (Gmail, Outlook) receives an email, it runs 4 checks to decide whether it goes to the inbox or to spam: With all 4 passing, your email has strict alignment and deliverability improves a lot.

​
SPF (Sender Policy Framework)

A TXT record in your DNS that lists which servers may send from your domain. When RQE sends from noreply@yourdomain.com, Gmail queries the SPF of yourdomain.com and verifies that the sending server is on the list. Example (the one RQE generates when you register your domain):
~all (soft fail): unlisted servers are marked as suspicious without being rejected. Harden it to -all (hard fail) once you confirm that all your legitimate traffic goes out through listed servers.
If you already have SPF for another provider (Mailgun, Sendgrid, Google Workspace), merge the include: entries into a single record; don’t add another TXT. Multiple SPF records break verification.

​
DKIM (DomainKeys Identified Mail)

A cryptographic signature of the content, made with an RQE private key. Your domain publishes the public key in DNS via 3 CNAME records. When the email arrives, Gmail takes the signature from the header, downloads the public key from the CNAME, and validates it.
The tokens (abc123, …) are generated when you register your domain and come in the response from POST /domains/register. DKIM also makes your domain appear in the signed-by: of the header in Gmail web: a signal of legitimacy for the end user.

​
DMARC

The policy on what to do if SPF or DKIM fail. It’s the strongest of the 3 against spoofing. Example:
pct=100 applies the policy to 100% of traffic. It’s common to start with pct=10 and increase gradually.
DMARC reports — managed by RQEWith rua=, receiving servers send daily reports on what % of your traffic passed SPF/DKIM. The record RQE generates for you points that rua to a mailbox managed by RQE: we receive and process those reports for you — no external service or XML reading needed. Use the exact value shown in your dashboard under Domains (the d-<id> is unique per domain).

​
MAIL FROM domain (custom)

Without extra configuration, the mailed-by: that Gmail sees is amazonses.com — the provider’s domain, not yours. That lowers SPF alignment from strict to relaxed. With a Custom MAIL FROM domain (in RQE, the bounce.yourdomain.com subdomain), the mailed-by: becomes your domain and SPF ends up strict. RQE configures it with a single CNAME record, included among the 7 that are generated when you register the domain:
Custom MAIL FROM is not mandatory: can_send doesn’t require it and emails arrive fine without it. But it improves SPF alignment, especially with strict clients like ProtonMail or enterprise Outlook. Recommended for large volumes.
The most common mistake: assuming SPF alone is enough.SPF is not evaluated against the From domain, but against the Return-Path domain. Without a Custom MAIL FROM, the Return-Path is @amazonses.com: your SPF passes, but it passes for amazonses.com, so it doesn’t align with your From and contributes nothing to DMARC.In other words, adding include:amazonses.com to your SPF does nothing on its own unless you also publish the Return-Path record. What covers DMARC in that scenario is DKIM, not SPF.

​
The verification process in RQE

1

Register the domain

POST /domains/register with { "domain": "yourdomain.com", "sender_name": "My Company", "sender_email": "noreply@yourdomain.com" } (all three fields are required). RQE generates the 8 DNS records and returns them. See Domains.
2

Configure the 8 records

In your DNS provider (Cloudflare, GoDaddy, Route 53, etc.):
  • 1 TXT domain verification
  • 3 CNAME DKIM
  • 1 TXT SPF (merge with existing if applicable)
  • 1 TXT DMARC
  • 1 MX send + 1 TXT send (Return-Path / Custom MAIL FROM)
3

Wait for propagation

5–10 minutes on Cloudflare/Route 53. Up to 48h on slow providers.
4

Verify

POST /domains/:domain/verify checks the domain verification, the 3 DKIM CNAMEs, and the MAIL FROM records (SPF and DMARC are not validated there: a sweep of ours resolves them every 6 hours). With the domain and DKIM verified, the response includes can_send: true and you can send from *@yourdomain.com.

​
Reputation: what decides the inbox once auth is right

Having all 4 records green does not guarantee the inbox. Authentication proves the email is yours; reputation decides whether they want it. This is the most common support case: a fully configured domain that still lands in spam.
Reputation belongs to the domain, not the IP.Gmail and Outlook mostly evaluate the domain that signs DKIM (the d= in the signature). That reputation follows you even if you change providers or servers. This is why the problem is almost never fixed by “switching IPs”.
If the From says @yourdomain.com but the links point elsewhere, filters read it as a spoofing signal: it’s a classic phishing technique. It happens unintentionally when open/click tracking wraps links with a shared domain. The fix is a tracking domain (links.yourdomain.com), so links and the pixel stay aligned with your From. See Tracking.

​
Warming: how to break in a new domain

A new domain has no history, so receivers distrust it by default. Warming means raising volume gradually and consistently, so the provider accumulates positive signals. Reference ramp for a brand-new domain: From there, increase roughly 1.4x per day until you reach your target volume. The higher the target, the longer the ramp: for tens of thousands per day, plan for four to six weeks.
These figures are ceilings, not goals. Exceeding them burns the domain, but sending 20 emails a day doesn’t warm it either: without consistent volume the provider never builds history, and every send looks like a stranger again.During warming, watch two numbers: bounces below 4% and complaints below 0.08%. If you exceed them, slow down and find the cause before ramping further.
One detail decides the outcome: who you send to first. Start with your most engaged contacts — those who open, reply, and asked to hear from you — and save cold outreach for when the domain already has history. Early opens and replies are the signal that builds reputation.

​
Use subdomains to contain risk

Send transactional and marketing email from separate subdomains (for example send.yourdomain.com and news.yourdomain.com). If a campaign draws complaints, the damage stays contained in that subdomain and your critical email — passwords, receipts — keeps landing. The same applies when you send on behalf of third parties: a subdomain shared by several senders has shared reputation, and one sender with bad lists is enough to drag everyone down.

​
How to test that your domain is set up right

1

Send to an external mailbox

Send a test to a Gmail address that is not on your own domain. An email leaving your domain and coming back to your domain through an external provider is the classic signature of spoofing: Google penalizes it even when authentication is perfect. It’s the test that produces the most false negatives.
2

Open 'Show original'

In Gmail, message menu → Show original. Look for three lines:
What matters is that the DKIM domain is yours, not amazonses.com. If it says amazonses.com, the domain identity is missing: your email is signed, but not in your name.
3

Check the 'via'

If Gmail shows yourdomain.com via amazonses.com, you’re missing the Custom MAIL FROM. It still arrives, but that’s the line that makes readers hesitate.
Don’t test with made-up addresses. Deliberately triggered hard bounces count against your reputation just the same.

​
Do you need a dedicated IP?

Almost certainly not. It’s the question that comes up most when something lands in spam, and it’s rarely the answer. By default your email goes out from a pool of shared IPs with established reputation, and you benefit from it on day one. A dedicated IP starts with no history at all: it has to be warmed up, and until then it delivers worse. It makes sense when all three conditions hold at once:
  • High volume: on the order of hundreds of thousands of emails per month.
  • Consistent volume week over week. With sporadic sending the IP “cools down” between batches and every campaign starts from scratch.
  • Bounces and complaints under control (bounces below 2%). With a high rate, a new IP burns during its own warm-up.
If you don’t meet all three, the shared pool will deliver better. And in no case does a dedicated IP offset damaged domain reputation: that’s fixed with clean lists and engagement, not with infrastructure.

​
Next steps