What SPF record does Twikey use?

With Twikey SMTP, add include:_spf.twikey.com to the existing SPF policy before its final all mechanism. If no SPF record exists and Twikey is the only sender, use v=spf1 include:_spf.twikey.com ~all. Publish one SPF record only.

Which DKIM selectors does Twikey use?

Twikey uses app for production and test for its beta environment. Create CNAME records from app._domainkey on your domain to app._domainkey.twikey.com and from test._domainkey to test._domainkey.twikey.com, then enable DKIM in Twikey.

Which platform sends email with rDNS mail.twikey.com?

mail.twikey.com is associated with Twikey's SMTP sending path. Twikey documents a:mail.twikey.com as an advanced SPF authorization. Treat rDNS as a source clue, then confirm ownership with the Return-Path, DKIM signing domain, source IP, and current DMARC data.

Does Twikey need both SPF and DKIM to pass DMARC?

No. DMARC passes when either SPF passes with an aligned Return-Path or DKIM passes with an aligned signing domain. I configure both where supported because DKIM survives forwarding more reliably and SPF provides another valid path.

Should I add Twikey SPF when using custom SMTP?

Only if Twikey infrastructure actually transmits the message or the custom design specifically requires it. With Custom SMTP selected, use the SPF and DKIM requirements of the transmitting system and verify the identifiers in a received message.

When can I change Twikey DMARC to p=reject?

Change to p=reject after DMARC reports show that Twikey and every legitimate sender consistently pass aligned SPF or DKIM. Stage enforcement, investigate valid failures, retain aggregate reporting, and keep an existing quarantine or reject policy instead of weakening it.

Learn

DMARC

How to set up DMARC/DKIM/SPF for Twikey

Matthew Whittaker

Co-founder & CTO, Suped

Published 11 Jul 2026

Updated 11 Jul 2026

10 min read

Summarize with

For Twikey SMTP, publish one SPF record that authorizes _spf.twikey.com, add the app and test DKIM CNAMEs, enable DKIM in Twikey, and publish DMARC at _dmarc on the From-address domain. I start DMARC at p=none, verify aligned authentication in real messages, then move to p=reject after every legitimate sender is accounted for.

Choose the sending path first

Twikey SMTP uses Twikey's mail infrastructure and the DNS records below. Custom SMTP shifts SPF, DKIM, Return-Path, and reputation requirements to that SMTP system. Do not authorize Twikey in SPF when Twikey is not the system that transmits the message.

Add your domain

Twikey does not have a separate domain-verification screen for this email integration. The domain is the part after @ in the From address, and Twikey validates the configuration when I run its test. The public Twikey email guide documents both Twikey SMTP and custom SMTP setup.

Open settings. In Twikey, go to Settings, Integrations, then Email integration.
Select transport. Choose Twikey SMTP Server for the records on this page, or Custom SMTP server if another system will transmit the mail.
Set the sender. Enter a From address on the domain I control, such as Billing <billing@example.com>. The visible From domain must match the domain where I publish DKIM and DMARC.
Delay saving. Leave the integration open while publishing SPF and DKIM. Run Test and Save only after DNS resolves publicly.

Twikey email integration and From address settings

Twikey SMTP

DNS ownership. I publish Twikey's SPF authorization and both Twikey DKIM CNAMEs.
Operational profile. Twikey queues mail and usually sends it within minutes.

Custom SMTP

DNS ownership. I use the actual SMTP operator's SPF and DKIM instructions.
Connection data. Twikey needs the SMTP host, port, TLS choice, and credentials.

Set up SPF

SPF authenticates the envelope sender, also called the Return-Path. With Twikey SMTP, I add Twikey to the single SPF TXT record on the Return-Path domain. Because Twikey supports Return-Path alignment, a correctly configured message can pass aligned SPF for DMARC.

Inspect DNS. Find the existing TXT value beginning with v=spf1. Never publish a second SPF record at the same hostname.
Add Twikey. Insert include:_spf.twikey.com before the final all mechanism. Keep every existing authorized sender.
Count lookups. Keep SPF within the ten DNS-lookup limit. Twikey notes that its validation does not resolve nested includes, so a complex valid record can still fail its interface test.
Verify alignment. Send a Twikey message and confirm smtp.mailfrom uses my organizational domain, not only that SPF returns pass.

New SPF record for Twikey-only sendingDNS

Name: example.com
Type: TXT
Value: v=spf1 include:_spf.twikey.com ~all

If an SPF record already exists, merge Twikey's include into it. Replacing the whole record can break authentication for other mail streams. I use the a:mail.twikey.com mechanism only when the supported include causes a lookup problem, because the hostname can follow an IP change.

SPF checker

Find SPF syntax issues, lookup limits, and weak records.

?/16tests passed

The check should return one syntactically valid SPF policy and show Twikey's authorization before the terminal all mechanism. A permerror means receivers cannot reliably evaluate the record, even when Twikey's own test appears successful.

Do not force SPF alignment

A custom SMTP service might not let me use an aligned Return-Path. In that case, I expect SPF alignment errors and rely on aligned DKIM for DMARC. A message passes DMARC when either aligned SPF or aligned DKIM passes.

Set up DKIM

Twikey delegates two selectors by CNAME. The app selector covers production and the test selector covers the beta environment. I publish both on the same domain used in the From address, then enable DKIM inside the email integration.

Create app. Add app._domainkey as a CNAME pointing to app._domainkey.twikey.com.
Create test. Add test._domainkey as a CNAME pointing to test._domainkey.twikey.com.
Disable proxying. If the DNS host supports proxying, leave both mail CNAMEs DNS-only. Remove any TXT record at either selector that conflicts with the CNAME.
Enable signing. Return to Twikey, select Enable DKIM, run Test, confirm success, and click Save.

Twikey DKIM CNAME recordsDNS

Name: app._domainkey.example.com
Type: CNAME
Value: app._domainkey.twikey.com

Name: test._domainkey.example.com
Type: CNAME
Value: test._domainkey.twikey.com

Twikey DKIM enabled with successful validation

What a valid message shows

The Authentication-Results header should show dkim=pass and a header.d domain that matches or is a subdomain of the visible From domain. A published CNAME alone does not prove that Twikey signed the message.

Set up DMARC

DMARC belongs at _dmarc on the visible From domain. It checks identifier alignment and tells receivers what to do when both aligned SPF and aligned DKIM fail. I begin with p=none so reporting reveals every sender without changing delivery.

Check first. Look up _dmarc.example.com. If a valid policy already uses p=quarantine or p=reject, keep that enforcement level and fix Twikey rather than weakening the policy.
Create one record. Publish the exact starter record below as TXT at _dmarc. Replace the example reporting address with a monitored mailbox or DMARC reporting destination before production use.
Keep relaxed alignment. The default relaxed modes accept an authenticated subdomain of the From domain. I tighten aspf or adkim only for a documented requirement.
Collect reports. Wait for aggregate reports, group Twikey traffic by source and DKIM domain, and confirm aligned pass results before enforcement.

Starter DMARC recordDNS

Name: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com

The DMARC record generator creates a policy with reporting and alignment options. Use one rua destination, make sure it accepts aggregate XML, and avoid publishing multiple DMARC TXT records.

DMARC checker

Look up a domain's DMARC record and catch policy issues.

?/7tests passed

A valid lookup should return one DMARC record with a recognized version, policy, and reporting URI. The checker confirms DNS syntax, while a real Twikey message confirms whether the identifiers actually align.

A pass must be aligned

SPF or DKIM can pass for an unrelated domain while DMARC still fails. I compare smtp.mailfrom and header.d with the domain in header.from. At least one passing identifier must share the same organizational domain under relaxed alignment.

Verify and troubleshoot

I verify in two places: Twikey's built-in Test action confirms its configuration, and an independently received message confirms what mailbox providers evaluate. DNS success without a signed message is incomplete verification.

Run Twikey Test. Open Settings, Integrations, Email integration, click Test, and wait for a success message before Save.
Receive a message. Trigger a real mandate, payment notification, or dunning test to a mailbox I control. Check junk if it does not reach the inbox.
Read authentication. Inspect Authentication-Results for spf=pass, dkim=pass, and dmarc=pass. Confirm the passing SPF or DKIM domain aligns with header.from.
Check both selectors. Resolve app._domainkey and test._domainkey. Each must return its Twikey target without a CNAME loop or competing record.
Separate custom SMTP. When custom SMTP is selected, inspect that system's message identifiers. A Twikey CNAME or SPF include does not repair authentication added by another transmitter.

Successful SPF and DKIM test in Twikey

For the quickest end-to-end check, send a Twikey test message to the email tester below. It reports the visible From domain, Return-Path, DKIM signature, DMARC result, and common content or transport faults in one result.

Email tester

Send a real email to this address. Suped shows a results button when the test is ready.

?/43tests passed

If the result fails, fix the first authentication fault before judging inbox placement. DNS updates often appear within the record's TTL, but cached results can remain until that TTL expires. Re-test with a newly generated Twikey message after every change.

Failure symptom

SPF permerror. Multiple SPF records, bad syntax, a loop, or more than ten lookups.
DKIM neutral. Missing selector, conflicting DNS data, or signing not enabled.
DMARC fail. Authentication passed only for a domain unrelated to the From domain.
No test mail. Bad From formatting, a Twikey queue delay, junk placement, or SMTP rejection.

Corrective action

SPF repair. Merge senders into one policy and reduce lookup-producing mechanisms.
DKIM repair. Correct both CNAME targets, wait for TTL expiry, and enable DKIM.
DMARC repair. Make either smtp.mailfrom or header.d align with header.from.
Delivery repair. Review Twikey's test status and Activity > Email errors, then retry.

Get alerted when it breaks

A passing test is a point-in-time result. Twikey infrastructure, DNS edits, selector changes, and newly added senders can change authentication later. I monitor aggregate DMARC data continuously and alert on a sustained change in aligned pass rates or an unknown source.

Route reports. Send rua reports to a processor that can parse XML, retain history, and group records by sending source.
Baseline Twikey. Record its normal source IPs, app or test DKIM use, aligned SPF rate, aligned DKIM rate, and daily volume.
Alert on change. Investigate a new source, a sharp failure increase, a missing DKIM selector, or unexpected volume before enforcement blocks valid mail.
Retest after edits. Trigger a Twikey transaction after any DNS or integration change and compare it with the established baseline.

Use Suped for continuous detection

Suped is our DMARC platform and the best overall fit for this workflow. It turns aggregate reports into identified sources, detects authentication issues, provides specific fix steps, and sends real-time alerts. Its unified monitoring also covers SPF, DKIM, blocklist status, and deliverability signals, so a Twikey failure is visible without reading XML manually.

Use DMARC monitoring to confirm Twikey remains authorized while other business mail streams continue to pass. Hosted DMARC and Hosted SPF are useful when policy staging or frequent sender changes make direct DNS edits slow.

Secure your domain with p=reject

Move to p=reject only after Twikey and every other legitimate source consistently pass aligned SPF or aligned DKIM. I treat enforcement as a staged change backed by report evidence, not as a DNS switch made immediately after setup.

Inventory senders. Identify every source in DMARC reports, including low-volume transactional systems and subdomains. Classify unknown traffic before authorizing it.
Prove Twikey alignment. Confirm recent production messages use aligned app DKIM or aligned SPF. Also verify the test selector if the beta environment sends mail.
Stage quarantine. Use p=quarantine with a limited pct value, review failures, then increase coverage. Keep the existing stronger policy if the domain already enforces quarantine or reject.
Apply reject. Set p=reject after legitimate aligned pass rates are stable. Decide whether subdomains need an explicit sp policy and continue reporting.
Keep rollback data. Record the previous policy, DNS TTL, owner, and approval. If valid mail fails, fix its alignment first and use a controlled policy rollback only when business impact requires it.

DMARC enforcement gates

Use report evidence and controlled policy changes rather than a fixed calendar date.

Observe

p=none

Identify all legitimate sources and confirm Twikey authentication.

Stage

p=quarantine

Quarantine a limited percentage and investigate every valid failure.

Enforce

p=reject

Reject unauthenticated mail after legitimate streams consistently align.

Full enforcement exampleDNS

Name: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=reject; rua=mailto:dmarc@example.com

Use Suped to stage enforcement

Suped maps verified and unverified sources, flags specific alignment failures, and gives steps to fix each issue before policy changes. Hosted DMARC supports controlled policy staging, while alerts show whether a Twikey change affects valid traffic. That combination makes p=reject safer to reach and easier to maintain.