Skip to main content
Related: How to setup a custom sending domain SPF, DKIM and DMARC work together to protect your email reputation and to protect your users from phishing attempts. If you send a marketing email in Vero from john@yourdomain.com, SPF, DKIM and DMARC are the methods by which Gmail, Outlook and other email providers confirm you’re allowed to send from yourdomain.com.

​
How Vero configures SPF and DKIM

When you add a custom domain to Vero you will see two DNS records. Take the screenshot below. DNS Screenshot

​
DKIM verification

When you add the TXT record for default._domainkey.saas.getvero.com, you’re proving that you own the domain in question. In this case we’re proving we own saas.getvero.com. Here’s the process in practice:
  • Vero generates a private key (kept securely on our side) and a corresponding public key. The public key is published as the p= part of the default._domainkey.saas.getvero.com DNS value.
  • When Vero sends an email, we attach a DKIM-Signature header:
    • d= is set to the sending domain (saas.getvero.com).
    • s= points to the DNS selector (default). This is how Gmail, etc. know to find default._domainkey.saas.getvero.com.
    • b= contains a signature. This is a hash we generate and then encrypt using the secret private key.
  • The receiving mail server:
    1. Recalculates the hash of the email headers/body.
    2. Fetches the public key from default._domainkey.saas.getvero.com.
    3. Uses the public key in the DNS record to decrypt the value in b=. It compares this with the recalculated hash (mentioned in #1 above).
  • If the hashes match then DKIM succeeeds, i.e. DKIM = pass.
This ensures the email truly came from a server authorized to send for your domain and that it hasn’t been tampered with before it arrived in your inbox.

​
SPF verification

SPF works slightly differently:
  • Your domain’s SPF record declares which mail servers are allowed to send on your behalf.
    • When Vero sends an email, the Return-Path is set to a Vero-controlled email and domain. In our example above this will be something like HASH@track.getvero.com.
    • Recipient servers, like Gmail, will use the Return-Path to look up the domain track.getvero.com and relevant SPF records.
  • The receiving server checks the sending IP against that Return-Path domain’s SPF record.
    • SPF records can be “chained”. You’ll notice track.getvero.com delegates SPF records to various domains and IPs.

​
DMARC checks and reporting

SPF checks : Does the Return-Path domain authorize the sending IP? DKIM checks : Does the email carry a valid signature? Was it sent by a server who has access to the secure private key. DMARC ties SPF and DKIM together. It checks for alignment : do either SPF or DKIM “line up” with the visible From address? It asks: “Take the results of SPF and DKIM, and make sure that at least one passesand matches the visible From domain.” Let’s say we’d sent an email from info@saas.getvero.com, DMARC checks that at least one of SPF or DKIM passed and also that the from address info@saas.getvero.com actually matches the SPF or DKIM values. You might ask why this is important? The reason is:
  • SPF checks use domain in the Return-Path value.
  • DKIM checks use the domain specified in the DKIM header.
If you do not have DMARC setup then anyone on earth could setup Sendgrid, Mailgun, Vero, etc. and have valid SPF and DKIM checks…but then send with a from address like info@yourdomain.com. For clarity, imagine this email: 
From: ceo@yourdomain.com
    Return-Path: bounce@mailer-service.com
    DKIM: d=mailer-service.com (valid signature)
In this example, SPF and DKIM could both pass for mailer-service.com. They’d be valid. And, yet, neither of those match ceo@yourdomain.com. That’s what DMARC solves. It checks that either the domain in Return-Path or the d= DKIM header align with ceo@yourdomain.com. After checking, DMARC then enforces your policy:
  • p=none → just monitor.
  • p=quarantine → send suspicious mail to spam.
  • p=reject → reject suspicious mail outright.
DMARC also enables reporting. Providers send you daily/weekly/monthly reports showing who is sending on behalf of your domain, whether they pass/align, and whether spoof attempts are being blocked. These reports help you monitor your domain’s email health and catch any misconfigurations.

​
Bringing it all together

  • SPF checks the envelope sender (Return-Path).
  • DKIM checks a cryptographic signature against your DNS.
  • DMARC ensures at least one of SPF or DKIM both passes and matches your From domain, and lets you choose what to do if they don’t.
When configured correctly in Vero, these three work together to protect your brand and ensure your emails reach the inbox.

​
What email headers look like

Using Gmail’s “View Original”, here’s a snippet of some headers from a real email sent by Vero. This email is one of our own emails (we use Vero of course). Email Headers A copy of the headers, sensitive aspects removed: 
Delivered-To: REDACTED@getvero.com
    Received: Thu, 18 Sep 2025 00:43:02 -0700 (PDT)
    Return-Path: <return-REDACTED@click.getvero.com>
    Received: from REDACTED.greenarrowmail.com (REDACTED.greenarrowmail.com. [165.140.254.99])
        by mx.google.com with ESMTPS id REDACTED
        for <REDACTED@getvero.com>
        Thu, 18 Sep 2025 00:43:01 -0700 (PDT)
    Received-SPF: pass (google.com: domain of return-REDACTED@click.getvero.com designates 165.140.254.99 as permitted sender) client-ip=165.140.254.99;
    Authentication-Results: mx.google.com;
        dkim=pass header.i=@getvero.com header.s=default header.b=REDACTED;
        spf=pass (google.com: domain of return-REDACTED@click.getvero.com designates 165.140.254.99 as permitted sender)
        dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=getvero.com
    Reply-To: hello@getvero.com
Here’s what this all means.
HeaderMeaning
Delivered-ToWho the email was sent to. If you’re receiving the email, this is likely to be your email address.
Return-PathThis is kind of like a hidden from address. It’s the envelope sender. Vero sets it to a Vero-controlled domain, e.g. click.getvero.com. This email and domain is used for SPF checks.
Received-SPFShows whether the sending server’s IP was authorized by the SPF record of the Return-Path domain.
Authentication-Results spf=passAnother header confirming SPF passed. The sending IP matched the SPF record for the Return-Path domain.
Authentication-Results dkim=passConfirms DKIM passed. The message was signed with a DKIM signature for getvero.com and the signature validated.
Authentication-Results dmarc=passConfirms DMARC passed. At least one of SPF or DKIM passed and aligned with the visible From address**.**

​
A and PTR records (less common)

Most customers will never need to configure A or PTR records — Vero manages these by default. However, in some cases we may ask you to create them when you’re sending from your own branded domain using Vero’s infrastructure. Here’s what they are and why they matter:

​
What an A record does

An A (Address) record maps your sending hostname (like mail.yourdomain.com) to a specific IP address — in this case, one of Vero’s sending IPs. It ensures that when mail providers look up your domain, it resolves to the same IP address used to send messages. Example: 
mail.yourdomain.com → 198.51.100.12

​
What a PTR record does

A PTR (Pointer) record does the reverse — it maps an IP address back to a domain name. This is known as reverse DNS (rDNS). Example: 
198.51.100.12 → mail.yourdomain.com
When both records point to each other, it’s called forward-confirmed reverse DNS (FCrDNS). This is a strong trust signal for mail providers like Gmail and Outlook.

​
Why Vero sometimes asks you to set these up

Even though your emails are being sent from Vero’s infrastructure, we may ask you to add A/PTR records to make the sending IP and domain appear as if they belong to your own brand. This is useful when:
  • You’re sending from a custom subdomain (like mail.yourdomain.com).
  • You are paying for dedicated IP’s.
  • You want the sending IP’s reverse DNS (PTR) to match your domain.
  • You’re establishing dedicated sending reputation for your domain.
For example, if your Vero sending IP is 198.51.100.12, we may ask you to create:
  • An A record : mail.yourdomain.com → 198.51.100.12
  • A PTR record : 198.51.100.12 → mail.yourdomain.com
This helps ensure:
  • Mail servers see consistent, aligned DNS data (A ↔ PTR match).
  • Your “From” domain, DKIM, and envelope sender align with network identity.
  • You build a strong domain reputation that reflects your brand, not Vero’s shared infrastructure.

​
Summary

RecordDirectionPurposeManaged by
A recordDomain → IPForward lookup; shows where your mail server livesUsually you
PTR recordIP → DomainReverse lookup; confirms mail server identityUsually Vero
SPFTXT recordLists authorized mail serversYou (guided by Vero)
DKIMTXT recordPublishes public key for signaturesYou (guided by Vero)
DMARCTXT recordDefines handling/reporting policyYou
✅ In short: A and PTR records help make your sending domain and IP appear as one — strengthening your reputation and improving deliverability.