How to set up DMARC/DKIM/SPF for Supy
To authenticate Supy emails sent with your domain in the From address, have Supy activate the sending domain, publish its DKIM and custom Return-Path DNS records, and add a DMARC TXT record. I start new DMARC deployments with p=none and test real Supy messages before increasing enforcement.
Get the DNS values from Supy for your account. I found no public Supy authentication guide confirming reusable SPF values, DKIM selectors, or a self-service setup menu. If your domain already has p=quarantine or p=reject, keep that policy while configuring Supy.
Add your domain
I first confirm whether Supy sends using the business domain or a Supy-owned address. Your DNS changes affect authentication for your domain only; a Reply-To address on your domain does not make it the sending domain.
Start at the Supy website, choose Contact us, then Live chat, or use your existing account support channel. Supy provides this public contact route; its public pages do not establish a domain-authentication settings path.
- Confirm the sender. Obtain a recent Supy email and identify the visible From domain. Give Supy that exact domain and the sender address you want to use.
- Request activation. Ask Supy to enable custom-domain sending, DKIM signing, and a custom Return-Path for your account. Request every DNS record with its type, host, and complete value.
- Verify ownership. Publish any ownership-verification token Supy supplies. Enter the host exactly once, accounting for DNS interfaces that append your domain automatically.
- Confirm activation. After publishing the authentication records below, ask Supy to confirm DNS verification and active signing for the intended From domain. Request a fresh message to validate the result.
I keep the record instructions with the support request so the DNS administrator can distinguish ownership verification, DKIM, and the Return-Path configuration.
Illustrative screenshot of Supy's Contact us page with Live chat highlighted.
A verified contact email and an authenticated sending domain are different checks. I wait for confirmation that Supy is actually signing outgoing messages with the requested domain.
If Supy confirms that your messages use only a Supy-owned From domain, do not add guessed Supy records to your business domain. Ask whether custom-domain sending is available for the specific message type you need.
Set up SPF
Supy supports Return-Path alignment. Ask Supy to assign and activate a custom bounce domain under your domain, such as bounce.example.com. SPF is checked against that envelope sender domain, rather than the visible From address.
I publish only the SPF-related records Supy supplies. There is no verified universal Supy SPF include, and the DNS records used by supy.io itself are not instructions for customer domains.
- Get the assigned host. Request the exact custom Return-Path hostname and its required TXT, MX, or CNAME records. Treat bounce.example.com as an illustration, not a Supy default.
- Publish the supplied records. If Supy supplies a CNAME, use that delegation as instructed. Do not add TXT or MX records at the same CNAME owner name.
- Preserve existing SPF. If Supy requires a TXT change at a hostname that already has SPF, merge the authorized mechanism into that single SPF record. Keep other legitimate senders and the final all mechanism.
- Validate the result. Check the actual Return-Path domain below. For a TXT-based policy, stay within SPF's limit of 10 DNS-querying terms, including nested includes, and avoid duplicate SPF records.
Enter the assigned envelope sender hostname in the SPF checker. A correct SPF record at example.com does not validate mail whose Return-Path uses a different subdomain.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
With relaxed SPF alignment, bounce.example.com and a From address at example.com normally share the same organizational domain. With aspf=s, the domains must match exactly; a custom bounce subdomain does not satisfy that stricter setting.
If a tested Supy message still uses a provider-owned Return-Path, SPF can pass while SPF alignment fails. That message still passes DMARC when DKIM passes with the required domain match. Adding an include to your root domain does not change its Return-Path.
Set up DKIM
I request DKIM records for the exact domain Supy will use in the visible From address. Supy needs the corresponding private signing key; publishing an unrelated public key cannot enable signing.
Obtain the selector names and either their CNAME targets or complete TXT public keys from Supy. Do not guess a selector or copy another account's records.
- Create each selector. Add every Supy-issued DKIM host and value in authoritative DNS. A selector normally has the form selector._domainkey.example.com.
- Use the correct type. For CNAME records, copy the complete target and keep DNS proxying disabled. For TXT records, preserve the full public key without introducing spaces inside the key.
- Activate signing. Ask Supy to recheck DNS and confirm DKIM signing is enabled for the custom domain. DNS publication alone does not prove that outgoing emails are signed.
- Inspect a fresh message. Check dkim=pass and the signature's d= domain. Under relaxed DMARC alignment it must share the From domain's organizational domain; adkim=s requires an exact domain match.
DNS verification
The assigned selector resolves to Supy's expected public key. This confirms publication, but does not prove that Supy is signing the messages you send.
Message verification
A newly delivered Supy email has a valid DKIM signature with the required From-domain match. This is the check I use before enforcing DMARC.
Leave active DKIM selectors published while Supy uses them. During rotation, keep the old selector available until Supy confirms it is retired and messages already in transit no longer need it.
Set up DMARC
DMARC is published in your domain's DNS, independently of Supy. I check for an existing policy before making changes because the policy covers other services sending with the same From domain.
For a new deployment without an enforcement policy, use p=none while collecting reports. Keep an existing p=quarantine or p=reject policy and repair Supy's authentication without weakening it.
- Inspect the existing record. Look up TXT at _dmarc.example.com, replacing example.com with your From domain. Check any inherited parent policy before adding a subdomain override.
- Create one policy. If there is no applicable policy, publish the initial TXT value below. Edit an existing record rather than adding a second DMARC record at the same hostname.
- Configure reporting. Replace dmarc@example.com with a mailbox or reporting destination you control. Complete external reporting authorization if the destination is on another domain.
- Check public DNS. Validate the resulting record and send a fresh Supy email. DMARC passes when SPF or DKIM passes with the required From-domain match; both methods do not have to pass.
Initial TXT value at _dmarc.example.comtext
v=DMARC1; p=none; rua=mailto:dmarc@example.com
The example reporting address must be replaced before publishing. A normal mailbox receives raw aggregate report files; it does not automatically turn them into monitoring data or alerts.
Use the DMARC record generator to build the record with your real domain and reporting destination. Then validate the published DNS value below.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
A successful DNS check confirms the policy is readable. It does not confirm that Supy messages pass DMARC, so I also test a message generated by the actual Supy workflow.
p=none requests monitoring without a DMARC quarantine or rejection request. Receiving systems still apply their own spam and security checks.
Verify and troubleshoot
I test the Supy message type that will run in production, using its intended sender address. A manually composed email sent through a different system does not verify Supy.
Our email tester prompts you to send a message to a unique test address and returns a full diagnosis. Trigger the Supy message directly to that address rather than forwarding an existing email.
- Send through Supy. Use an authorized test recipient for the relevant Supy notification or business workflow. If that workflow cannot target the test address, inspect the original received headers instead.
- Check identities. Compare the visible From domain, the Return-Path domain, and the d= domain of each DKIM signature. Read authentication results added by the receiving system.
- Resolve DNS errors. Check for an automatically duplicated domain suffix, incomplete DKIM values, duplicate SPF or DMARC records, and CNAME records configured as proxied web traffic.
- Retest after changes. Allow previous DNS answers to expire according to their TTL, ask Supy to recheck activation, and generate another message. Confirm dmarc=pass for every production sender domain.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
The tester gives a quicker result than waiting for aggregate reports. I use reports afterward to confirm that other Supy message types and receiving systems see consistent authentication.
When troubleshooting manually, run these read-only lookups with your actual From domain, assigned Return-Path host, and issued DKIM selector. The names below are examples, not Supy-provided values.
Look up the published authentication recordsbash
dig +short TXT _dmarc.example.com dig +short TXT bounce.example.com dig +short CNAME bounce.example.com dig +short MX bounce.example.com dig +short TXT selector._domainkey.example.com dig +short CNAME selector._domainkey.example.com
A successful selector lookup still needs a passing signature on a real message. Similarly, SPF pass on a provider-owned domain does not establish SPF alignment for your domain.
I use the following results to choose the next check rather than changing every DNS record at once.
|
|
|---|---|
SPF pass, DMARC fail | Envelope domain; DKIM |
DKIM fail | Selector; key; signing |
SPF permerror | Duplicates; lookup limit |
DMARC pass, spam | Reputation; content |
Use received-message results to choose the next check.
Authentication does not guarantee inbox placement. If DMARC passes but delivery still fails, use the actual SMTP rejection or bounce reason to investigate the delivery problem.
Get alerted when it breaks
Suped is our DMARC reporting and email authentication platform. Its DMARC monitoring connects reported Supy traffic with authentication failures, issue diagnostics, and notifications so the team has a concrete starting point for repairs.
For a domain already sending aggregate reports to Suped, I configure alerts around known legitimate traffic. Aggregate reports arrive after processing by receiving systems, so these notifications are not instant alerts for every individual email.
- Confirm reporting. Verify that current aggregate reports appear for the sending domain. Use the reporting destination assigned to your organization, not the example mailbox above.
- Verify the source. Identify Supy using a known authorized message and authentication data before marking it as a verified sending source. Do not approve traffic based only on an rDNS label.
- Enable notifications. In Suped's organization settings, open Notifications and enable DMARC failure alerts. Configure the available recipients and threshold for the team responsible for DNS and Supy.
- Investigate regressions. Open the affected records in Suped, inspect SPF and DKIM diagnostics, and compare DNS history with recent changes. Send Supy the failing message details and rerun a live test after repair.
Keep an operational check
Suped combines the report history, issue guidance, and alerts needed to follow Supy authentication over time. Keep a recurring Supy test as well, especially after sender-address changes or DKIM rotation.
Secure your domain with p=reject
I move to p=reject after confirming that legitimate senders use valid DKIM with the required domain match, including every Supy workflow. A healthy Supy test alone is insufficient when other systems send using the same domain.
Suped's Hosted DMARC supports policy management and staging from the dashboard. Use Suped's source data and issue diagnostics to establish readiness before changing the policy.
- Cover a full sending cycle. Review enough reporting history to include infrequent notifications, scheduled reports, and other legitimate mail. Investigate failures by verified source rather than relying only on an overall pass rate.
- Require working DKIM. Confirm Supy signs with your domain and that messages pass DKIM. Forwarding often breaks SPF, so do not rely on SPF alone before enforcement.
- Stage enforcement. For a domain starting at p=none, move to p=quarantine, review legitimate failures and delivery errors, then move to p=reject. Keep reporting enabled throughout.
- Check scope and monitor. Review parent and subdomain policies, including any sp setting, before enforcement. Keep Suped alerts enabled and retest Supy after DNS or sender configuration changes.
Final TXT example after all legitimate senders are verifiedtext
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Replace the example reporting address with your working destination. If Suped hosts your policy, make the policy change there; do not publish a conflicting TXT record beside its delegated configuration.
p=reject requests rejection of mail that fails DMARC. Receiving systems make the final handling decision, and the policy does not stop impersonation that uses a different domain.
Repair Supy before sending under enforcement
If the domain already uses p=reject, keep it. Finish Supy's custom-domain activation and verify a fresh message before enabling the production workflow.
FAQ
I use the original received headers to distinguish Supy's sending identity from contact addresses and infrastructure names. Each identifies a different part of the message.
Keep the Supy-issued DNS instructions with your change records. They are the reference for account-specific selectors and Return-Path settings.
Suped associates the .supy.io rDNS suffix with Supy. Treat it as a source-identification clue, not proof that a message is authorized. Compare the connecting IP and authentication results with a known legitimate Supy message before approving the source.
No universal Supy SPF include was verified in the public setup material. Request the exact records for your account and custom Return-Path from Supy. Do not assume include:supy.io or copy SPF values used by Supy for its own mail.
SPF can pass for a provider-owned Return-Path that does not match your visible From domain under the applicable DMARC alignment mode. DMARC fails if there is also no passing DKIM signature with the required domain match. Activate the custom Return-Path and confirm custom-domain DKIM signing.
Keep an existing p=reject or p=quarantine policy. Have Supy activate the correct domain and DNS records, then verify a new message before enabling production sending. p=none is the starting recommendation for a new deployment without an enforcement policy.
Your business domain does not need Supy authentication records solely because it appears in Reply-To or the message body. SPF and DKIM authenticate the domains actually used in the envelope sender and signatures; DMARC evaluates the visible From domain. Request custom-domain sending if you want your business domain in From.
Retest when the authoritative DNS returns the new records, then allow cached answers to expire according to their prior TTL. Ask Supy to rerun verification if activation is pending. A live test message confirms the sending path sooner than an aggregate report, which arrives on the receiving system's reporting schedule.
