Email for Dating Apps: Deliverability, Retention, and Revenue

A founder’s guide to how email works, how to reach the inbox, and how to turn notifications into conversations and subscriptions.

Why I care about email

I was configuring mail servers before I started building dating businesses.

While studying computer science at university, I worked part time as a system administrator. I set up Linux servers and email for organizations. SMTP and POP3 were things I had to make work. I also dealt with NNTP newsgroups, a separate system for discussions that people still used, and configured WinGate on Windows.

When someone could not receive a message, there was a concrete problem to investigate. A service had stopped. A name did not resolve. A server was rejecting a connection. A configuration that looked correct was wrong in one small but consequential way.

The interfaces have changed enormously since then. Hosted services handle much of the infrastructure. Gmail has become the default mailbox for many people. Sending an application email can be a single API request.

That convenience makes it easy to overlook what happens afterward.

Today, when I look at email in a dating product, I see a direct connection between infrastructure and growth. A verification message helps someone finish registration. A message notification helps two people continue a conversation. An appropriate reminder can bring a user back while a potential match is still interested.

If those emails arrive late, disappear into spam, or become annoying enough that people block them, the effect reaches far beyond an email dashboard. Fewer people respond. Conversations stall. Other users experience the product as inactive. Retention suffers.

In Retention is King: How to Balance Your Unit Economics, I explained why retention determines whether acquisition costs can turn into a profitable dating business. In How to Actually Grow a Dating Business, I described the user journey from registration to meaningful engagement. Here, I want to explain one of the technical foundations underneath those growth loops.

You do not need to become a mail administrator to understand this article. You do need enough understanding to choose your tools, ask useful questions, and recognize when a reassuring dashboard is showing you only part of the story.

At SkaDate, our usual stack is Amazon SES for transactional email and Sendy connected to Amazon SES for marketing email. I will use that setup throughout the article, while explaining the decisions that apply to other providers too.

The business outcome behind an email

Imagine a small dating app with a promising new conversation.

Anna sends Daniel a message. Daniel has already closed the app. The product sends an email telling him there is something to reply to. He returns that evening, responds, and Anna receives a notification of her own.

The value comes from the conversation continuing. The email helps that happen.

Now change one detail. Daniel’s email never reaches his inbox. He returns three days later. Anna has stopped checking. Both people can come away believing that nobody replies on this app, even though the original interest was mutual.

This is a hypothetical example, but it captures a practical problem: dating depends on coordination between people whose attention is elsewhere much of the time.

A large registration count can hide this problem. Your database may contain thousands of profiles while a particular user sees very few relevant, responsive people nearby. What matters is the availability of compatible people within a useful period of time. Product teams often call this marketplace liquidity. I explain the challenge of creating that initial network in The Foundation: Solving the Cold Start Problem in Dating. Email helps people return while other relevant people are still active.

Email can improve the timing of participation. It can also waste attention. Bringing a user back to an irrelevant recommendation, a deleted profile, or an already-read message teaches that user to ignore the next notification.

I therefore evaluate an email program at several levels. Can we reach the user? Does the message accurately describe something useful? Does the user return? Does a valuable action happen after the return? Does the program improve retention without generating excessive complaints or opt-outs?

Email and push are the two main notification channels in this technical series. For a mobile dating product, I would normally prioritize push for immediate events such as a new message or match, then use email selectively. Push puts the alert on the device where the app already lives, and a tap can return the user straight to the conversation. That can make responding easier for the user and reduce the business’s dependence on inbox placement, email volume, and email sending costs.

Large mobile apps make extensive use of push. Tinder supports both push and email notifications; its public documentation does not establish how often it emails every user. My recommendation is to use the channels according to the situation: a timely push for an active mobile user, and a useful email when push is unavailable or a different reminder is appropriate.

Permissions, delivery systems, and failure modes differ. Push requires permission and can be disabled; an uninstalled app cannot receive its usual app notifications. Email remains valuable for account communication, web users, and appropriate reactivation. Coordinate both channels so one event does not produce several redundant interruptions. This article focuses on email.

Where email lives

Start with four separate things: your application, a sending service, a mailbox provider, and an email client.

Your dating application knows that Anna sent Daniel a message. It decides whether to create a notification and what that notification should contain.

A sending service, such as Amazon SES or SendGrid, takes responsibility for attempting delivery. It connects to the receiving system, handles the transport, and produces information about delivery attempts and failures.

A mailbox provider stores the recipient’s email. For Daniel’s Gmail address, that provider is Google. For an employee using a company email address, the underlying provider might be Google Workspace, Microsoft 365, or another mail host.

An email client displays the mailbox. Apple Mail, Outlook, and a browser tab open to Gmail are examples of ways to read email. The client and the mailbox provider can be different companies. Someone can read a Gmail mailbox in Apple Mail.

That distinction matters when interpreting statistics. An Apple Mail open does not mean the recipient has an iCloud address. A company domain does not tell you which software the recipient uses to read its messages.

Your website host is another separate decision. Hosting a dating site on one cloud does not require using that cloud for employee mailboxes or application delivery. You can host the application in one place, send through Amazon SES, and receive support emails through Google Workspace.

For a founder, the useful question is who owns each part. Who decides to send? Who transports the email? Who stores the recipient’s mailbox? Who monitors failures? Confusion between those responsibilities leads to support conversations in which every vendor correctly explains that the problem belongs somewhere else.

SMTP, POP3, IMAP, and the browser

A protocol is an agreed set of rules that computers use to communicate. Email uses several, because sending a message and reading a mailbox are different jobs.

SMTP means Simple Mail Transfer Protocol. It is the core protocol used to submit and relay email. A sending server establishes a conversation with a receiving server, identifies the sender and recipients, transfers the message, and receives a response.

When your application calls an email provider’s HTTP API, your developers may never write SMTP commands. The provider still uses email transport protocols downstream. The API changes how you hand the message to your provider; it does not make the recipient’s mail system disappear.

POP3 means Post Office Protocol version 3. It retrieves messages from a mailbox. Historically, it was common to download mail to a desktop computer. Depending on settings, copies may remain on the server or be removed after retrieval.

IMAP means Internet Message Access Protocol. It supports working with a mailbox stored on the server, including folders and message state. It is useful when the same mailbox is accessed from a phone, laptop, and other devices.

Webmail adds a browser interface. Your browser communicates with the web service over HTTPS; the provider manages the mailbox and delivery infrastructure behind it. Gmail’s interface is therefore one layer of a larger system.

TLS encrypts connections between systems that support and negotiate it. It helps protect a message in transit over that connection. This is different from the domain authentication mechanisms we will discuss later, and from end-to-end encryption in which only the intended participants can decrypt the content.

The practical lesson is simple: POP3 and IMAP belong primarily to mailbox access. For a dating application’s outbound notifications, your team will mostly work with an email API or SMTP submission, DNS, authentication, delivery events, and recipient preferences.

Follow one message from the app to the inbox

Let us return to Anna and Daniel.

First, the application records Anna’s message. Next, it determines whether Daniel should receive an email. Perhaps he is currently reading the conversation. Perhaps he disabled message emails. Perhaps the account has been paused. The notification decision should account for those conditions.

If the email is appropriate, the application prepares it and hands it to a sending service. In our SkaDate transactional setup, it connects to the Amazon SES SMTP endpoint. Amazon SES also offers an API, which is another way software can submit mail. The important distinction is that the application requests the send; the sending service then attempts delivery.

Amazon SES accepting the request means it has accepted responsibility for processing that request. It does not establish that Daniel has received or read anything.

The sending infrastructure finds the destination’s mail servers through DNS and attempts SMTP delivery. The receiving server may accept the message, temporarily defer it, or reject it. If accepted, the mailbox system applies its own filtering and placement decisions.

Daniel may receive it in an inbox category, in spam, or in another destination affected by mailbox rules. If he sees it, he still has to understand the message and decide whether to act.

These are separate milestones:

1. Notification created: The product decided an email was eligible.

2. Provider accepted: The sending service accepted the request.

3. Receiving server accepted: The destination server accepted responsibility for the message.

4. Inbox placement: The message reached an inbox rather than spam or another destination.

5. Human engagement: A person interacted with it.

6. Product outcome: The person returned and did something valuable.

An email provider’s delivery event usually refers to receiving-server acceptance. The remaining milestones require other evidence. This is why a high delivery rate can coexist with a weak notification program.

The visible sender and the envelope sender

An email has information that the recipient normally sees and routing information that is usually hidden.

The visible From address might be notifications@notify.example.com. The display name might be Example Dating. A Reply-To address can tell the email client where a human reply should go, such as your support mailbox.

The SMTP envelope has its own sender address, called MAIL FROM. This address is used for delivery-status messages such as bounces. When the message reaches final delivery, its Return-Path header normally records this reverse-path address. Reply-To and Return-Path therefore serve different purposes. [1]

Think of a parcel that contains a letter. The name on the letter, the address for a personal response, and the logistics address for a failed delivery can differ. Email has a similar separation, although the precise routing rules are more technical.

Other headers help reconstruct what happened. Message-ID identifies a message for tracing, although your application also needs its own identifiers. Received headers record transport hops. Authentication-Results records checks performed by a receiving system. When investigating a problem, your team needs the original message or full headers, not only a screenshot of the visible body.

MIME describes how a message can contain different content types. A typical notification can include both plain text and HTML alternatives. The email client chooses an appropriate representation. Attachments and inline resources also use MIME structures.

Founders rarely need to inspect these details daily. They should know that an email is a structured message with routing and authentication information. A beautiful HTML template is only one component.

DNS records that matter for email

DNS is the internet’s naming system. It publishes information that other systems need when interacting with your domain. Several record types matter for mail.

An MX record identifies servers that accept incoming email for a domain. If someone sends mail to support@example.com, the sending system looks up the relevant mail routing information. MX records can include priorities so that multiple receiving servers can be used.

An A record maps a hostname to an IPv4 address. An AAAA record does the equivalent for IPv6. A PTR record works in the reverse direction, associating an IP address with a hostname. Receiving systems often expect valid forward and reverse DNS for outbound mail infrastructure.

TXT records can contain policy information such as SPF and DMARC. DKIM public keys may be published directly in DNS or reached through provider-supplied CNAME records. A CNAME is an alias from one DNS name to another.

These records are connected, but they do different jobs. An MX record tells the world where to deliver incoming mail. It does not, by itself, authorize a service to send mail using your identity.

In practice, your email sending service supplies DNS records for your team to publish. The important step is putting each record under the correct domain name. Your developer or service provider can do this for you; as a founder, you should ask them to show that a real outgoing message passes the checks.

DNS changes also take time to become visible because systems cache answers. When a provider says a record is missing, check the exact name, value, authoritative DNS service, and caching behavior before repeatedly changing settings.

My recommendation is to maintain a small inventory: every sending domain, the service using it, its purpose, and the person responsible for its DNS configuration. That inventory becomes valuable when you add a campaign tool or migrate providers.

SPF: the DNS record that authorizes sending servers

SPF means Sender Policy Framework. It is a policy published as a TXT record in your domain’s DNS. In plain English, the record tells receiving mail systems which servers are allowed to send using your domain in the message’s delivery envelope.

Suppose your dating site uses Amazon SES to send notifications. Your SPF setup authorizes the appropriate Amazon SES sending infrastructure. When a message reaches Gmail, Gmail can compare the sending server with that published authorization.

Why does this matter? Email was not originally designed to make every sender prove who they were. A spammer can put someone else’s domain into parts of an outgoing message. Without an SPF policy, receiving systems cannot use your published SPF authorization to check whether the server is allowed to send for that envelope domain.

With SPF configured, an unauthorized server can fail that check. This helps receivers identify impersonation attempts and gives legitimate mail a stronger technical foundation. It does not make it impossible for a criminal to type your brand into the visible From address. DKIM and DMARC add other checks, especially the connection to the address the user actually sees. [2]

The practical task is to authorize all the services that genuinely send for you. Here, “services” means tools such as Amazon SES, SendGrid, your support platform, or your employee email system when it sends using the relevant domain. It does not mean adding Gmail and Yahoo merely because your customers receive mail there.

Your team should maintain one valid SPF policy for each relevant domain, incorporating its legitimate senders. Creating a separate SPF record for every sending tool at the same domain can break the configuration.

For a quick technical check, ask your developer to use MXToolbox SuperTool. It includes SPF, DKIM, DMARC, DNS, and blocklist lookups. These tests help find configuration problems; a test email received in a real mailbox is still useful evidence.

DKIM and message signatures

DKIM means DomainKeys Identified Mail. It adds a digital signature to an outgoing email. Your sending service creates the signature, and the receiving system checks it using information published in your domain’s DNS.

Think of your company sealing an outgoing document. Someone receiving it needs a way to check that the seal is genuine and that the protected content has not changed. DKIM provides a technical version of that seal for email. [3]

Why does this matter? A fake dating-site security message might look convincing: your brand name, logo, and a link asking the user to sign in. A visual imitation alone cannot produce a valid DKIM signature for your domain without access to its signing key.

If DKIM is not configured, your legitimate messages arrive without that domain-backed signature. Receivers lose an important way to check your mail, and your domain also lacks the DKIM evidence that DMARC can use to distinguish your own messages from impersonation. Missing DKIM does not itself give a criminal access to your servers; it leaves an important protection unused.

For a founder, the implementation is usually straightforward: enable the sending service’s DKIM setup and publish the DNS records it provides. Amazon SES and other major sending services handle the actual signing. Your team checks that messages received in Gmail or another mailbox pass DKIM for the intended domain.

If you change sending providers or domains, test the new setup before moving all your traffic. Also test after introducing a service that rewrites email content, because changing protected content after signing can invalidate the signature.

DMARC and the identity people recognize

DMARC means Domain-based Message Authentication, Reporting, and Conformance. It is another policy published in DNS. It connects the domain in the visible From address with the domain authenticated through SPF or DKIM.

This solves a problem founders can easily recognize. Your customer sees notifications@yourdatingapp.com and assumes the message came from your business. A successful technical check for some unrelated domain would not establish that connection. DMARC asks whether the authentication supports the sender identity the user actually sees.

A message can pass DMARC when SPF or DKIM passes with an appropriately matching domain. Your team should configure both, even though an individual message does not need both to pass DMARC. [4]

DMARC also lets you state how you want receivers to treat messages that fail. The common policy choices are none, quarantine, and reject. Start by monitoring legitimate sending, then move toward quarantine or rejection once your own services are configured correctly.

Without DMARC, you have not published that visible-domain protection and handling policy. Criminals may attempt to impersonate your domain in fake password resets, payment notices, or “you have a new match” messages. A correctly configured enforcement policy helps receiving systems keep those unauthenticated impersonations away from users.

No single record prevents every kind of deception. Someone can register a lookalike domain or misuse a compromised legitimate account. The benefit here is protection against unauthorized use of your actual domain, alongside clearer authentication for your own mail.

DMARC reports can also show which sending systems are using your domain and whether their authentication passes. A reporting service can turn those technical reports into a dashboard. For a founder, the useful question is simple: are all our real senders configured, and are outsiders trying to impersonate us?

SPF, DMARC, and DKIM working together: a hacker’s email

Let us use two domains:

• dating.site — our dating business.

• atacker.site — the hacker’s domain.

The hacker wants to send our users a fake security email. The goal is to make them open a fraudulent login page and enter their passwords.

The fake email looks like this:

From: support@dating.site

Delivery address: bounce@dating.site

Message: “Your account has been blocked. Follow this link to restore access.”

An email has two sender addresses that matter for this example.

The From address is the sender address presented to the user. The delivery address is a separate address used behind the scenes, including for delivery failures.

Gmail’s normal message view does not display this delivery address. Finding it requires inspecting technical message details.

The hacker can put dating.site into both addresses without owning our domain. Let us see what changes as we add protection.

We configure SPF: Gmail can check the sending server

We publish an SPF record in our domain’s DNS. It identifies the servers authorized to send mail using dating.site as the delivery domain.

For example, our setup authorizes the Amazon SES infrastructure we use.

The hacker sends the fake email from their own server, keeping bounce@dating.site as the delivery address.

Gmail checks the SPF record for dating.site and discovers that the hacker’s server is not authorized.

The hacker can still send the message. What changes is that Gmail can now detect the unauthorized sending through SPF. Gmail decides how to handle that result alongside its other checks.

The hacker has another option: use their own domain in the delivery address.

From: support@dating.site

Delivery address: bounce@atacker.site

Message: The same fake account warning.

The hacker configures SPF for atacker.site, authorizing their own server.

Now SPF can pass — for atacker.site, the hacker’s domain.

But the user does not see that delivery address in Gmail’s normal message view. They see support@dating.site in the From field and may believe the email came from our dating business.

The hidden delivery address is bounce@atacker.site. If Gmail displayed it alongside the From address, the user could notice the unfamiliar domain and recognize the mismatch. In the normal view, that clue is hidden.

That is the problem: SPF successfully checks the hacker’s hidden domain, while the user sees and trusts our domain.

We therefore need a check that connects authentication to the visible From address. That is what DMARC provides.

We configure DMARC: reject emails that impersonate our visible From

The hacker’s email has already passed SPF:

From: support@dating.site

Hidden delivery address: bounce@atacker.site

SPF: Passed for atacker.site.

The user sees support@dating.site. They do not see the hacker’s delivery address in Gmail’s normal message view.

We now publish a DMARC policy for dating.site and choose reject. Our instruction to receiving services is:

“If an email shows dating.site in From, but its authentication does not confirm dating.site, reject it.”

At this stage of our example, we have not configured DKIM for our domain, so DMARC relies on the SPF result.

Gmail sees that SPF authenticated atacker.site. But the email claims to come from dating.site.

The hacker has proved their right to send for atacker.site. They have provided no authentication for dating.site.

The email therefore passes SPF but fails DMARC.

Our reject policy tells Gmail to reject this impersonation. For a receiving service following that policy, the result is rejection: the fake email is not delivered to the user.

This closes the gap left by SPF alone. The hacker cannot satisfy DMARC merely by passing SPF for their own hidden delivery domain while displaying our domain in From.

Our legitimate emails can pass because their authentication corresponds to dating.site. DKIM provides another way to supply that confirmation.

We configure DKIM: our real emails carry a digital signature

When our sending service sends a genuine email, it adds a digital signature associated with dating.site.

The signature is created using a secret signing key. The corresponding public key is published in DNS so receiving services can check it.

The signature is tied to protected parts of the email, including the From address and message content.

Gmail reads the signing domain from the DKIM signature itself. It then retrieves the public key for that signing domain and checks the signature.

It does not simply take the visible From address and assume that its domain signed the message.

Now consider the hacker’s options.

Option A: claim that dating.site signed the fake email.

The hacker does not have our secret signing key, so they cannot create a valid signature for dating.site using their own key. The signature check will not pass.

Option B: sign the email using atacker.site.

That signature can be completely valid. Gmail can confirm that atacker.site signed the message.

But the visible From still says support@dating.site.

DMARC detects that the valid signature belongs to atacker.site, while the visible From belongs to dating.site.

In our example, both SPF and DKIM now authenticate the hacker’s domain. Neither authenticates our domain.

The email still fails DMARC, and our reject policy still asks Gmail to reject it.

Option C: send the email without a DKIM signature.

There is no signature to verify, so the message provides no authentication through DKIM. Its SPF result still confirms only atacker.site, so it fails DMARC again.

The hacker also cannot take a genuine signed email, replace a protected login link with a fraudulent one, and keep the signature valid. Changing the signed content causes verification to fail.

Why have both SPF and DKIM?

They provide different evidence:

• SPF: Is the sending server authorized for the delivery domain?

• DKIM: Is the signing domain’s signature valid, and is the signed content intact?

• DMARC: Does successful SPF or DKIM authentication correspond to the domain in the visible From address?

Having both is useful when a legitimate email is forwarded.

Gmail may receive our genuine email from a forwarding server that our SPF record does not authorize. SPF can then fail, while the DKIM signature remains valid if the protected content is preserved.

DMARC can accept that matching DKIM signature as confirmation of dating.site.

The rule to remember is that DMARC can pass through either matching SPF authentication or a matching DKIM signature. Both do not have to pass.

A missing or failed DKIM signature therefore does not automatically send an email to Spam. A message can still pass DMARC through matching SPF authentication. The receiving service considers these results, our DMARC policy, and its own filtering rules.

Together, these tools help receiving services distinguish mail authorized by dating.site from messages that merely display our name and address.

Reputation and the difference between delivery and visibility

SPF, DKIM, and DMARC are email authentication tools: they help a receiving service check whether a message’s claimed sender identity is supported by the domain’s configuration. Reputation answers the next question: given this sender’s behavior, how should the receiving service treat the message?

That second question affects visibility. Gmail might accept an email from your authenticated domain and still place it in Spam, where the user is unlikely to read it. Good authentication creates the foundation; a history of wanted, relevant messages helps your emails remain visible.

A domain can authenticate perfectly while sending messages people dislike. A technically valid message can contain a misleading subject, arrive too frequently, or refer to an account the recipient barely remembers creating.

Receiving systems can evaluate domains, sending IPs, message content, links, traffic patterns, and recipient behavior. Their decisions are proprietary and can differ between providers. There is no universal public score that fully predicts where every email will land.

For a founder, this means reputation is partly a product outcome. Your onboarding controls affect address quality. Your notification frequency affects complaints. Your moderation system determines whether you repeatedly promote interactions from accounts that users later discover are fraudulent.

Suppose your application sends a new-message email for every message a scammer generates before being banned. Your delivery infrastructure may work exactly as configured. The product has still sent unwanted mail and damaged trust. Reputation management therefore requires cooperation between engineering, growth, support, and trust and safety.

Inbox categories also deserve a sensible interpretation. An email in Gmail’s Promotions category is not the same as an email in spam. A promotional campaign can legitimately belong in Promotions. Your objective is wanted, usable communication, with measurement of the outcome that matters to the product.

When someone says, “Our delivery rate is 99%,” ask what event that rate counts. Then ask how performance differs across Gmail, Outlook, Yahoo, and other destinations. A blended number can hide a severe problem with the mailbox provider used by most of your audience.

Shared IPs, dedicated IPs, and warmup

An IP address identifies a sending server on the network. When Amazon SES delivers your email to Gmail, Gmail sees the IP address of the Amazon SES server making that connection. That address has its own sending history and reputation.

With shared IPs, your mail travels through a pool used by other customers of the sending service. The service manages that pool. It can be a sensible starting point because it already carries regular traffic, although other customers’ behavior can affect the shared reputation.

With dedicated IPs, the sending addresses are reserved for your account. This gives you more control and a clearer relationship between your own sending behavior and the IP’s reputation.

Within Amazon SES, standard dedicated IPs provide known, static addresses. Managed dedicated IPs automate more of the work and can add or remove addresses as your traffic changes. For a small dating site with low or irregular volume, shared IPs can be a better fit than a dedicated address that receives little consistent traffic. [5]

Warmup means gradually building a new sending IP’s history. A brand-new address that suddenly sends hundreds of thousands of emails gives receiving systems little evidence that this is normal, wanted traffic.

You can use provider automation for this. Amazon SES enables automatic warmup by default for standard dedicated IPs. Its managed dedicated IP service goes further, adapting warmup to actual sending patterns and to each receiving provider, such as Gmail or Yahoo. Amazon SES warmup documentation and managed dedicated IPs explain the options.

Other providers offer similar features: SendGrid supports automated IP warmup. Ask which feature is included in your chosen plan and whether it is enabled.

Automatic warmup takes care of a technical ramp-up. You still choose the audience and the messages. Start with people who recently joined or actively use the product, monitor results, and avoid introducing an old, unresponsive list as your first major campaign.

For an early dating product, I would prioritize correct setup, useful notifications, and a suitable managed service. Dedicated IPs become a business decision when your sending volume and need for control justify them.

Separate email streams according to their purpose

The word transactional is used loosely. Some teams use it to mean every email their application sends automatically. That is too broad for decisions about preferences, risk, and legal classification.

A password reset responds to a specific account-access request. A receipt records a purchase. A digest of recommended profiles encourages future activity. All can be automated, but users have different expectations for each.

I find three operational categories useful:

• Essential account messages: Dating examples: Verification, password reset, security notice, receipt; Product treatment: Clear purpose and appropriate urgency.

• Subscribed product notifications: Dating examples: New messages, matches, activity digests; Product treatment: User controls and event relevance.

• Marketing: Dating examples: Offers, newsletters, reactivation campaigns; Product treatment: Appropriate permission and easy opt-out.

The table is a product design framework. Legal treatment depends on the actual message and jurisdiction. Adding an offer to an otherwise transactional message can change the analysis.

Marketing often reaches less-engaged users and can produce more complaints. Operational separation helps prevent a campaign backlog from delaying password resets and makes it easier to diagnose the stream causing trouble.

You can separate streams through subdomains, provider configuration, queues, credentials, reporting tags, and, where justified by volume, IP pools. For example, notify.example.com and news.example.com can make the distinction explicit.

Subdomains improve organization but do not create complete isolation. Mailbox providers can associate related identities, and Gmail aggregates some compliance assessments at the primary-domain level. Separate root domains introduce their own brand and reputation costs. I would make that decision deliberately rather than buying a disposable-looking domain whenever a campaign performs badly.

Keep your identity recognizable. The recipient should understand which product is contacting them regardless of the technical stream behind the message.

Blocklists and what a listing actually means

A blocklist is a database used to identify infrastructure or domains associated with unwanted or risky activity. Some lists concern IP addresses; others concern domains, including domains used in links.

Spamhaus is one prominent operator. Its IP and domain lists serve different purposes, and an individual mailbox provider decides how to use external intelligence alongside its own filtering. [6]

A public listing can explain a rejection. The absence of a public listing does not establish good inbox placement. Gmail can make a negative decision using information that never appears on a public lookup site.

When a listing appears, begin with the exact evidence. Which IP or domain is listed? On which list? Does an actual receiving-server error reference it? Is the affected IP controlled by your company or by your email provider?

Next, investigate the cause. It could involve an old imported audience, a compromised credential, excessive invalid recipients, or another sender in shared infrastructure. The corrective action depends on that cause.

If you control the problem, fix it before requesting removal. If the IP belongs to a provider, give that provider the rejection details and message identifiers. Its team generally controls the relevant IP-level remediation.

For a dating business, an especially damaging reaction is to keep sending the same unwanted campaign through fresh domains. It leaves the audience and product problem intact while adding inconsistent branding. A sustainable recovery requires changing the behavior that caused the issue.

Choosing the sending service and the campaign tool

For a founder launching a new dating site, I would usually start with a managed email service. Early sending volumes are often modest, so the monthly cost can be a reasonable price for a system that is ready to use.

By “managed service,” I mean a provider that combines sending infrastructure with a useful interface for logs, delivery statistics, templates, and routine email operations. Depending on the product and plan, you may also get bounce and complaint handling, unsubscribe tools, campaign features, team access, and support.

SendGrid is one example. Resend, Mailgun, Postmark, and Mailchimp Transactional, also known as Mandrill, offer different combinations of these capabilities. Compare the actual product and plan: an email API subscription does not always include a complete marketing campaign tool.

The early benefit is time. Your developers can integrate a service and use its existing reports instead of building every dashboard and operational screen. You can spend more attention on registration, conversations, payment conversion, and retention.

As the product grows, the calculation changes. Higher email volume makes the per-message premium more noticeable. Your team may also want greater control over infrastructure, reporting, and the campaign software it uses.

That is when I would consider a setup such as Amazon SES for transportation and Sendy for marketing campaigns. It can reduce sending costs and give you more flexibility, provided someone owns the setup and maintenance.

There are two purchases hidden inside many email subscriptions: the transport that attempts delivery, and the software that manages audiences, templates, campaigns, and reporting. Comparing those separately makes the price difference easier to understand.

My recommendation is to start with the service your team can operate reliably, then revisit the economics as usage grows. Also confirm that the provider accepts your specific dating use case and content before investing in the integration.

Our SkaDate stack and the role of Amazon SES

At SkaDate, we usually use Amazon SES for transactional mail and Sendy connected to Amazon SES for marketing campaigns.

In the transactional path, the dating application decides what to send and submits the message to Amazon SES using SMTP. In the marketing path, Sendy manages the campaign and uses Amazon SES for delivery. Amazon SES provides the email transport underneath both paths.

This gives the application a straightforward way to send registration, account recovery, and notification emails, while the marketing team gets a campaign interface for audiences and newsletters.

Amazon SES requires verified sending identities. New accounts begin with sandbox restrictions, which include limited sending and restricted recipients. Production access removes the sandbox recipient restriction, but does not remove the need to verify your sending identities. Sending quotas and throughput limits remain separate controls, and configuration is region-sensitive. [7]

You may hear this process described as getting “whitelisted.” I would use more precise language. Verifying a domain proves control of a sending identity. Production approval permits broader sending. A recipient’s allowlist is a separate concept. A suppression list prevents certain sends. None of these is a universal promise of inbox placement.

A custom MAIL FROM domain lets you use your own bounce-domain identity rather than the default Amazon SES domain. It needs the DNS configuration specified by AWS and can help achieve SPF alignment. Aligned DKIM can also satisfy DMARC. [1]

Configuration sets let your team associate sending behavior and event reporting with particular streams. Operationally, you want to distinguish account messages, product notifications, and campaigns in your data even when they use the same provider.

We also connect email events to Mixpanel. In our Amazon SES setup, we track Sent, Delivered, Opened, and Clicked so we can connect email activity with what people do in the dating product. This reporting connection is part of our implementation. A more integrated service such as SendGrid already provides built-in email statistics, although you may still send selected events to Mixpanel for product analysis. [8]

What Sendy adds

Sendy is email campaign software that you install on a server and connect to Amazon SES. Its license is a one-time purchase: the current listed price is $69, rather than a recurring monthly platform subscription. Amazon SES sending and your hosting are separate costs. [9]

Sendy provides a campaign interface, audience lists, templates, autoresponders, and reports, including opens, clicks, bounces, and complaints. For a dating business, it can be a practical way to run newsletters, recommendation campaigns, and appropriate reactivation emails.

The one-time license is only part of the cost. Someone still needs to run the server, apply Sendy updates, maintain the operating system and supporting software, protect access, keep backups, and monitor that scheduled campaigns actually send. Minor updates are included until the next major version; major-version upgrades can require another payment.

This is why we offer Managed Sending for clients on SkaDate Prime Ultimate, including a SkaDate-hosted Sendy account. The founder gets the campaign tool with an operational service around it.

If you self-host, budget for the person who maintains it. If you use our managed option or another provider’s hosted service, include that subscription in your total cost. The useful comparison is what the whole system costs to run reliably.

The actual economics of email

Email transportation can be remarkably inexpensive. The confusion begins when founders compare the raw sending fee of one service with a complete software subscription from another.

As checked on October 28, 2026, AWS lists outbound Amazon SES à la carte sending at $0.10 per 1,000 emails. Its Essentials plan lists $0.16 per 1,000 in the first volume tier. Additional features and data charges can apply, so the selected plan matters. [10]

Here is the sending-charge arithmetic before those extras:

Monthly recipient deliveries submitted:

• 10,000: Amazon SES à la carte base sending: $1.00; Amazon SES Essentials first-tier sending: $1.60.

• 100,000: Amazon SES à la carte base sending: $10.00; Amazon SES Essentials first-tier sending: $16.00.

• 1,000,000: Amazon SES à la carte base sending: $100.00; Amazon SES Essentials first-tier sending: $160.00.

Sendy adds its license and your hosting and maintenance costs to the applicable Amazon SES bill. It does not replace Amazon SES charges.

For a concrete comparison, Resend currently lists a $20-per-month Pro transactional plan with 50,000 emails, and a $90-per-month Scale plan with 100,000. At the latter volume, $90 is nine times Amazon SES’s $10 à la carte base sending fee. That comparison concerns the listed sending volume and entry subscription, not feature equivalence or a universal cheapest configuration. [11]

The absolute difference matters more than the headline multiplier. A $10 infrastructure bill becoming a $90 managed bill may be acceptable if it saves engineering work. A large monthly premium at higher volume deserves closer review. Use the vendor’s applicable tier, overages, and negotiated terms rather than extrapolating a small plan indefinitely.

SendGrid distinguishes its Email API offering from Marketing Campaigns. Mailchimp Transactional has its own purchasing model and relationship to Mailchimp plans. Their quotes should be built around the same workload before comparison. [12][13]

I would calculate total cost as software plus sending plus infrastructure plus optional services plus the people required to operate the system. Include dedicated IPs, event processing, retained logs, and support where relevant.

Then connect that bill to the product. A cheaply sent campaign that produces complaints and few valuable returns can be more expensive than its invoice suggests. Conversely, a modest investment that protects account access and improves replies can be worth far more than the sending fee.

Hard bounces, soft bounces, and retries

Imagine your dating site sends Daniel a new-message notification. Amazon SES takes that email to the mail system responsible for Daniel’s address, such as Gmail. That receiving system may be unable to accept or deliver it. The failure information travels back to your sending service. That is a bounce.

A hard bounce usually means a permanent problem with delivery to that address. The simplest example is an address that does not exist. If Daniel mistyped his email during registration, there may be no mailbox to receive the message. Repeating the attempt will not create one.

A soft bounce usually means a temporary problem. A familiar example is a full mailbox: the address exists, but its owner has run out of storage. A temporary receiving-server problem is another example. Delivery may become possible later, so the sending service can retry before reporting a final failure.

These are the useful terms for a founder. You do not need to read SMTP response codes to understand the business issue: some addresses cannot receive your mail permanently, while others may be reachable after a temporary problem clears.

Modern delivery services do much of the bounce handling for you. Amazon SES, SendGrid, and Mailchimp Transactional have mechanisms for recognizing failed deliveries and avoiding repeated attempts to addresses that should no longer be used. Amazon SES also handles delivery retries for temporary failures. [8]

A suppression list is a “do not send” list maintained by the provider. With Amazon SES bounce suppression enabled, an address that produces a hard bounce can be added automatically. Later send requests to that address can be accepted by Amazon SES without another delivery attempt because the address is suppressed. Your team should confirm that the relevant suppression settings are enabled. [21]

This protects you from repeatedly sending to an address already known to be invalid. It also protects the provider’s infrastructure. Repeated failures are a warning sign of poor address quality and can harm the sender’s reputation.

Automation cannot undo the first failed attempt. If a signup flow produces thousands of mistyped or invented addresses, those initial hard bounces still create a problem. The founder’s job is to watch the rate, find where bad addresses enter the database, and fix that source.

You generally do not need to build an entire bounce-management system yourself. Choose a provider with these capabilities, configure them correctly, and use its reports to understand what is happening.

Spam complaints and the feedback you can receive

A spam complaint is a recipient telling their mailbox provider that they consider your message unwanted. Someone can register for your dating app and later decide that its emails are too frequent, irrelevant, or difficult to stop.

The Gmail exception: Report spam does not identify the recipient

In the dating products I work with, Gmail can account for 85% or more of user email addresses. This is my observation from those products, not a universal market statistic. With that audience mix, Gmail’s behavior is central to how you manage email.

Imagine a user receives a notification from our dating app at user@gmail.com and clicks Report spam. Gmail receives the complaint, but it does not provide our sending service with a traditional recipient-level feedback report saying “user@gmail.com reported your message.”

Amazon SES therefore cannot automatically add that specific address to its suppression list solely because the user clicked Report spam in Gmail. The same limitation applies to SendGrid and Mailchimp Transactional, also known as Mandrill. A more expensive sending service does not make Gmail reveal the complaining recipient.

This means we can continue requesting emails to that address without knowing that the person complained. Gmail may filter later messages into Spam, while our sending service still records receiving-server acceptance as delivery. Delivered does not mean visible in the inbox, and no recorded complaint does not mean that no Gmail user complained.

SendGrid’s documentation explicitly distinguishes Gmail’s anonymous, aggregate reporting from traditional feedback loops that can identify recipients.

From the user’s point of view, there are several ways out. They can unsubscribe from a mailing list, block a sender, or report a particular email as spam. These actions have different consequences.

Gmail introduced its Block sender feature on September 22, 2015. Future messages from a blocked address are directed to that user’s Spam folder. The sender can still attempt delivery; the messages are filtered away from the inbox. Blocking also does not automatically remove the user from your mailing list. Google’s launch announcement and current Gmail help describe this behavior.

“Report spam” is a separate action. It tells Gmail that the message is unwanted; Google says it receives a copy and may analyze it to help protect users from spam and abuse. Google’s public guidance describes Block and Report spam separately. It does not establish that every Block click generates the same complaint event in a sender’s reporting. Report spam in Gmail

For the business, either outcome matters. A blocked sender loses visibility in that person’s inbox. Spam reports can also affect how the mailbox provider treats the sender’s mail. Making unsubscribe easy gives users a clear way to stop optional emails before frustration escalates.

Some receiving providers share individual complaint information through feedback loops. When a supported report identifies the recipient, Amazon SES with complaint suppression enabled, SendGrid, or Mailchimp Transactional can use it to stop further sending to that address. Yahoo operates a complaint feedback loop for enrolled DKIM domains. This individual-report-and-suppression workflow must not be assumed for Gmail. [14]

What Feedback-ID actually tells you

Gmail’s Feedback Loop helps identify problematic campaigns or categories of mail. A Feedback-ID header lets us associate messages with identifiers such as new-message, weekly-digest, or reactivation. Gmail can then provide aggregate complaint information associated with those identifiers. [15]

For example, the reporting may show that reactivation emails generate more spam complaints than new-message notifications. That tells us which campaign, audience, or notification type needs investigation. It does not give us the email addresses of the people who complained. Feedback-ID is a campaign-diagnostics tool, not a recipient-level suppression feed.

Use Google Postmaster Tools to understand Gmail’s reported spam rate and the feedback data available for your traffic. A low or zero complaint count in Amazon SES is not a substitute for Gmail’s own reporting.

Report spam and Unsubscribe are separate actions. An unsubscribe request can identify the relevant recipient or subscription, allowing our system or campaign service to stop that sending. If Gmail also offers an unsubscribe action when someone reports spam, that unsubscribe request is a separate mechanism; the spam report itself is not a personalized unsubscribe notification.

For our Gmail-heavy audience, the practical approach is to make unsubscribe easy, watch Postmaster and campaign-level feedback, and use product activity and notification preferences to decide when optional mail should stop. Provider-managed suppression still handles the failures and identifiable complaints the provider actually receives.

Watch the pattern behind complaints. Did a reactivation campaign reach people who no longer remembered the service? Did a “new match” email exaggerate what was actually waiting in the app? Did an opt-out stop working?

The delivery service can handle supported complaint and suppression mechanisms. Your team still controls the product decisions that make people want, ignore, or complain about the messages.

Validate addresses without blocking registration

Address quality begins during registration. Suppose someone mistypes their address and your application immediately starts sending welcome emails, match alerts, and reminders. The receiving system may report that the address does not exist, producing a hard bounce. A large number of such failures can damage your sending reputation.

With bounce suppression correctly configured, Amazon SES can add that failed address to its suppression list and avoid subsequent delivery attempts. That prevents repetition; it does not erase the initial failure. Preventing obvious address mistakes before sending is therefore useful. [21]

I would not automatically make email confirmation a blocking step in every dating signup flow. Asking someone to leave registration, open their inbox, find a message, and return can create substantial friction on mobile and desktop. Some people never make it back.

My preferred starting point is address validation with a service such as DeBounce, whose API uses the debounce.io domain. Your application submits the address for a technical check. The service can check its format, the domain’s mail setup, common domain typos, and signs that the mailbox is invalid, disposable, or uncertain.

This helps catch mistakes before your sending service attempts delivery. For example, an obvious typo in a Gmail domain can prompt the user to correct the address while they are still on the form.

Validation and ownership confirmation answer different questions. Validation asks whether the address appears usable. A confirmation link or code asks whether this particular person can receive mail there. An address can pass technical validation while belonging to someone else, and some servers make mailbox checks inconclusive.

I would use that distinction to design a gradual flow. Let the person enter the product where appropriate, then ask for a usable email address and encourage confirmation at a sensible moment. If signup does not collect email, invite the user to add it later. Explain the benefit: account recovery and useful reminders about conversations. An optional request can build the channel without blocking the whole experience.

Then test the tradeoff. Measure how many people leave at the confirmation step, how many complete registration, how many addresses bounce, and whether the users who continue reach meaningful conversations. If confirmation causes little abandonment and improves address quality, making it mandatory can be the better choice.

For Google or Apple single sign-on, when the integration supplies a verified email address, a second confirmation email is generally unnecessary. Use the verified identity returned by the sign-in service. In products I work with, manually entered email/password registrations can account for roughly 20% of signups; that is my observation, not an industry benchmark. [16][17]

A later change to the email address deserves a fresh ownership check. And a usable or verified email address does not by itself prove that a profile is genuine or that its owner consented to every marketing campaign.

Apple private relay addresses

When Sign in with Apple requests an email address, the user can choose Share My Email or Hide My Email. With Hide My Email, your app receives a private relay address instead of the person’s actual mailbox address. Apple forwards eligible mail from your app to that mailbox.

That gives a privacy-conscious user a way to register without revealing their everyday address. The relay address is legitimate and should be treated as a usable contact address, rather than rejected merely because it looks unfamiliar.

To reach it, your sending setup must satisfy Apple’s rules. Register the sending sources Apple requires and configure email authentication correctly. Test your real templates through Amazon SES, including your actual sending domain. A message that reaches an ordinary Gmail address can still fail Apple’s relay requirements. [18]

For retention, the limitation is that this channel remains under the user’s control. They can turn off forwarding for your app or developer in Apple Account settings. Once forwarding is disabled, your emails no longer reach their personal inbox. You cannot assume that an address collected at signup remains a permanent route back to the user. Manage Sign in with Apple settings

Simply uninstalling the app should not be treated as proof that forwarding has stopped. Removing an app from the phone, deleting an account inside the app, and disabling Apple’s forwarding are different actions. For reactivation, the relevant questions are whether the user still permits contact and whether the relay is still forwarding.

In August 2026, Apple announced that new relay addresses would begin using private.icloud.com later in the year; existing privaterelay.appleid.com addresses continue to work. Your address checks should allow both. [19]

My practical test is straightforward: register using Hide My Email, send an actual notification through the production configuration, and confirm that it arrives. Repeat that check when you change email providers or sending domains.

Let the provider handle bounces and suppression

In the days of running your own mail server, your team had to build or maintain much more of the logic for handling failed deliveries. Modern email delivery services take over much of that work.

Amazon SES, SendGrid, and similar providers can recognize failures and maintain suppression lists that prevent repeated sending to addresses already known to be invalid. With the appropriate bounce and complaint settings enabled, supported events can update those lists automatically.

For Amazon SES, think of the suppression list as the provider’s memory: “We already learned that sending to this address should stop.” If your application later requests another send to an address covered by the active suppression settings, Amazon SES can accept the request without attempting delivery. [21]

The recommendation for a founder is simple: use the provider’s built-in bounce handling and suppression features. Ask whoever configures the service to confirm that they are enabled and working. You usually do not need your developers to recreate that transport logic.

User preferences are a separate product responsibility. A marketing unsubscribe, a paused dating account, or an account deletion should also stop the appropriate optional mail. Your application and campaign tool must respect those choices even when the address is technically deliverable.

The provider protects delivery operations; your product decides which valid messages the user has asked to receive. Both can be handled with existing service capabilities and a clear configuration.

Unsubscribe that works for people and mailbox providers

Before looking at the technical implementation, consider what the user now sees. For years, many readers looking to leave a newsletter, including a Substack subscription, would scroll to the bottom of an email to find the unsubscribe link. Mailbox interfaces now make that choice much more visible.

In Gmail, eligible subscription messages can show an Unsubscribe link next to the sender’s name at the top. The user can act there instead of searching the email footer or recovering a forgotten account password. Gmail may show a confirmation dialog; a properly implemented one-click unsubscribe request does not require logging in to your service. Gmail’s unsubscribe guide

Gmail can also suggest unsubscribing from mailing lists based on signals such as how often a sender emails and how often the recipient reads those messages. Google introduced these suggestions in 2018. This makes sending more mail to an increasingly disengaged audience an especially weak retention strategy. Google’s explanation

In July 2025, Gmail introduced Manage subscriptions: a dedicated view of active subscription senders, with recent sending frequency and an Unsubscribe option. It gives people a single place to review mailing lists and ask Gmail to unsubscribe on their behalf. Manage subscriptions announcement

For your dating business, the implication is practical: the mailbox itself helps users decide which senders deserve attention. Make leaving optional email easy, and give people useful reasons to keep the messages they value.

The technical setup below is what lets your sending system cooperate with those mailbox controls.

Make the option visible in marketing and subscribed notification messages. A preference center can let users choose message alerts, match alerts, digests, and promotions separately. Include a straightforward way to stop all marketing mail.

Avoid asking someone to recover a forgotten password just to unsubscribe. A user who cannot easily stop unwanted mail has an obvious alternative: the spam button.

Gmail’s one-click requirement for affected marketing and subscribed mail involves message headers and an automated endpoint. The essential headers are List-Unsubscribe, containing an HTTPS URL, and List-Unsubscribe-Post, signaling List-Unsubscribe=One-Click. Under RFC 8058, the relevant headers must be protected by a valid DKIM signature. [22]

When the mailbox provider sends the unsubscribe POST request, your server must process it without a login, an additional confirmation page, or a redirect. Use a hard-to-forge token identifying the subscription so the action can work safely without exposing personal data in a simple readable URL.

The visible link in the email body and the header-based mechanism serve related but separate paths. Implement both. An ordinary preference-page link alone does not fulfill Gmail’s RFC 8058 requirement. [23]

Handle the request promptly and propagate it to future campaigns. Yahoo requires honoring these requests within two days; Google recommends fulfillment within 48 hours. Designing for immediate internal suppression is a practical way to avoid delays between systems. [24][23]

Essential transactional messages have different treatment. A user-requested password reset is not equivalent to a subscription promotion. In the United States, the FTC’s CAN-SPAM guidance distinguishes transactional or relationship messages from commercial email according to their purpose and content. Other jurisdictions have their own rules. [25]

For your product design, allow users to stop optional activity emails even when a team has labeled them “transactional” internally. A software label does not determine how a recipient experiences the message.

Mailbox provider requirements

Gmail, Yahoo, and Outlook publish sender requirements. Treat them as operating conditions for the destinations your audience uses.

For Gmail bulk sending, the requirements include SPF and DKIM, DMARC with alignment, appropriate DNS, TLS, low spam rates, and unsubscribe support for relevant messages. Gmail’s bulk classification considers traffic from the same primary domain, including subdomains. Splitting a campaign across subdomains does not automatically avoid that classification. [26]

Yahoo publishes its own requirements covering authentication, complaints, unsubscribe handling, and infrastructure. Microsoft has authentication requirements for high-volume senders to its consumer email services. The exact definitions and enforcement details should be checked in their current documentation. [24][27]

I would not turn compliance into a one-time launch task. A new vendor can introduce an unaligned sender. A template change can remove unsubscribe headers. A broken webhook can leave opt-outs unprocessed. A DNS cleanup can delete a record that another team still needs.

Assign an owner who can see across the whole email program. Growth should know when a campaign changes the audience. Engineering should know when a new sender changes authentication. Support should know how to distinguish a preference issue from a delivery issue.

Use actual received messages and provider observations to verify the configuration. A DNS record can exist while the production message uses a different identity from the one the team intended to configure.

Provider compliance is a baseline for reliable operation. Useful content, clear expectations, and respectful frequency remain necessary after every technical check passes.

Google Postmaster Tools deserves its own place in your routine

In the dating products I work with, Gmail can account for roughly 85% of user email addresses. That is my observation, not a claim about the global dating market. Your own distribution may differ, so measure it.

For an audience with that composition, understanding Gmail’s view of your traffic is essential. Google Postmaster Tools is one of the first tools I would configure.

It provides destination-side information that complements the events from Amazon SES. Add and verify your relevant domains, then give the people responsible for delivery access to the dashboards. Its data concerns personal Gmail accounts, arrives with a delay, and may be limited when volume is low. [28]

The Compliance dashboard in the newer interface makes the basic question much easier to answer: does Gmail consider our sending compliant with its applicable requirements?

It reports statuses such as Compliant, Needs work, or No data found. The checks include authentication, DNS, message formatting, encryption, spam rate, and relevant unsubscribe requirements. Compliance uses primary-domain reporting that incorporates subdomain traffic, and changes can take several days to be reflected. [28]

That last point matters for our separated sending streams. If marketing and transactional email use related subdomains, a green result for one piece of your setup does not justify ignoring the rest of the primary domain’s traffic.

The operational views I would review are summarized below. [32]

• Compliance: Which requirement needs investigation.

• Spam rate: Whether recipients are rejecting the email program.

• Authentication: Whether legitimate mail is passing the expected checks.

• Delivery errors: Which failures or deferrals require action.

• Encryption: Whether transport is protected as expected.

• Feedback Loop: Which identified campaign or stream is associated with complaints.

• Deliverability analysis: Which diagnostic recommendations deserve attention.

Older guides often show Domain Reputation and IP Reputation charts. Google says these legacy charts are being retired and excluded from v2. If you follow older troubleshooting instructions, check which interface they describe and use the current compliance and diagnostic views available to your account. [29]

Spam rate needs careful interpretation. Google recommends keeping it below 0.1% and avoiding 0.3% or higher. Those are operational thresholds, not targets to approach deliberately. [23]

The denominator is not simply every email your application attempted to send. Google’s metric concerns eligible inbox-delivered mail that users mark as spam. If much of your traffic is already filtered into spam, a low reported rate can be misleading. [28]

Here is a simplified hypothetical illustration. Fifty complaints divided by 100,000 attempted sends looks like 0.05%. If the relevant inbox-delivered denominator were 20,000, the ratio would be 0.25%. The events and eligibility rules behind the denominators explain why dashboards can disagree.

I would check Postmaster routinely and after substantial changes. Put campaign dates, volume changes, new templates, and DNS deployments on the same timeline. If complaints rise after a reactivation campaign, that context is more useful than staring at the graph alone.

When a status says No data found, investigate volume and data availability. Do not treat missing data as proof of compliance or failure. When a change has just been deployed, give delayed reporting time to catch up while checking real messages and sending logs immediately.

At larger scale, Postmaster’s v2 API can feed internal monitoring. Google now exposes compliance and statistics capabilities through that API. The human responsibility stays the same: someone needs to understand the signal and decide what to change. [30]

Content that earns the next open

The technical system gets your message to a place where it can be seen. The content determines whether seeing it was worthwhile.

Use a recognizable sender name and an accurate subject. If the email says someone sent a message, that message should exist and be available to the recipient. If it says there is a new match, the product should have created a real match under its actual rules.

Dating users are especially sensitive to the possibility that activity is manufactured. A misleading notification can undermine confidence in the whole service. A short-term increase in clicks is a poor trade if the return experience makes the user trust you less.

Make the main action easy to understand. A new-message notification should lead to the relevant conversation. A recommendation digest should lead to the promised recommendations. If the user needs to sign in, preserve the destination through that process.

On mobile, test the handoff to the app and the fallback to the web. A deep link is simply a link intended to open a specific destination within an application. Its value disappears if it opens the wrong screen or strands a user who does not have the app installed.

Use readable text and a layout that survives blocked images. Provide a plain-text alternative where appropriate. Test common clients, dark mode, narrow screens, and accessibility settings. A template should communicate its purpose even when decorative elements fail.

Keep tracking infrastructure understandable. A branded tracking domain can make links easier to recognize, but redirects still add dependencies. Your unsubscribe, security, and action links should continue working through the full production path.

Finally, monitor replies. People often reply to a notification when they need help or want it to stop. A valid, monitored response path can turn confusion into a support resolution before it becomes a complaint.

Privacy is part of the email experience

A dating notification can reveal something the user considers private before they click anything.

Email previews can appear on a lock screen, shared computer, or work device. A subject line containing a name, photo-related detail, sexual preference, or explicit message excerpt may disclose more than the user expected.

Decide how much information belongs outside the authenticated product. A generic message alert gives less context but provides more discretion. A personalized preview may help someone recognize an interaction but creates more exposure. Offer sensible controls where the product calls for them.

Consider the sender name too. A brand name alone can reveal membership in a specialized dating service. The onboarding and preferences experience should make the notification behavior understandable.

Your internal systems also need restraint. Avoid putting private conversation text into analytics event names, unnecessary logs, or tracking URLs. Use identifiers that let authorized systems find the relevant record without copying sensitive content everywhere.

Account-access links need special care. A magic link signs a person in or authorizes an action through a token. Tokens should expire and have a clearly limited purpose. Avoid sending them through tracking arrangements that expose the token to additional services without a deliberate reason.

Automated scanners can inspect links before the person clicks. Design verification and account-access flows so those scans do not unexpectedly consume a one-time action or change account state merely by fetching a URL. Your engineering team should test the chosen flow in real mail environments.

Privacy and conversion are connected here. A user who feels exposed by your emails may disable the whole channel or leave the service. Respecting their expectations protects your future ability to communicate.

The notification program I would build

I would begin with messages tied to concrete user value and expand only when their behavior is measured.

Account emails come first. Verification, password recovery, significant security changes, and payment-related communication need clear wording and a dependable path. They should explain what happened, what the user can do, and how to get help when the action was unexpected.

Next come conversation notifications. An unread message from a legitimate account is a clear reason to return. Before sending, check that the message remains unread and accessible. If a person sends several messages in a short burst, grouping them can be more useful than creating one email per message.

Match notifications can also be valuable, provided they accurately reflect the product’s matching behavior. Make the next step obvious. A user should understand why opening the app now creates a useful opportunity.

Likes and profile activity need more judgment. An individual popular user may receive enough activity to generate excessive mail. A digest or frequency limit can preserve the signal. Describe activity accurately, especially when access to details depends on a subscription.

Recommendation emails should reflect actual preferences, location, availability, and account quality. Sending a person back to profiles outside their criteria wastes both their attention and your sending reputation.

Onboarding reminders should help someone reach the first valuable interaction. If a missing profile photo prevents meaningful participation, explain the reason and provide a direct path to upload it. Repeating “Complete your profile” without understanding the blocker may achieve little.

Winback campaigns need a stronger reason than the passage of time. Perhaps there are now relevant new members nearby, a requested feature has improved, or an unfinished conversation remains useful. If nothing meaningful has changed, repeated reminders can reinforce the user’s original reason for leaving.

Offers and subscription promotions belong in their own category. Measure the resulting purchases, refunds, retention, and complaints. A discount can produce short-term revenue while bringing back users who still have a poor experience.

Here is a practical starting matrix, to be adapted to the product rather than copied blindly:

• Verify address: Check before sending: Still unverified and within resend limits; Destination: Confirmation flow.

• Password reset: Check before sending: Valid recent request and unexpired token; Destination: Secure reset flow.

• New message: Check before sending: Unread and accessible conversation; Destination: That conversation.

• New match: Check before sending: Match remains valid and visible; Destination: Match or conversation screen.

• Activity digest: Check before sending: Relevant activity remains available; Destination: Accurate activity summary.

• Profile reminder: Check before sending: Specific unfinished step still matters; Destination: That onboarding step.

• Reactivation: Check before sending: Credible value and eligible audience; Destination: The promised opportunity.

• Subscription offer: Check before sending: Eligible user and marketing permission; Destination: Clear offer and terms.

The same event can be appropriate for one user and excessive for another. The notification system needs enough product context to tell the difference.

Frequency, timing, and coordination with push

Sending more emails can increase immediate visits while making the channel less effective over time. That tradeoff needs measurement.

Apply frequency limits across the whole program. If every team owns its own limit, a user can still receive a message alert, a match alert, a digest, an onboarding reminder, and a promotion in the same hour.

A shared notification decision should consider message importance and the user’s recent experience. Essential requested account messages may need different rules from optional engagement emails. Within optional traffic, prioritize events that are most likely to lead to a valuable action.

Timing also changes meaning. A new-message alert can be useful immediately. A recommendation digest might work better when the user is likely to have time to browse. Use the user’s timezone when you know it and define a reasonable fallback when you do not.

Coordinate with push and in-app activity. If Daniel has already opened the conversation, suppress the delayed email. If he is active in the app, another out-of-app interruption may add little value. If push is unavailable, email can play a more important role, subject to his preferences.

Do not assume push delivery means the notification was seen. The decision should use reliable product activity where possible, and experiments where the evidence is ambiguous.

Batch related events. Ten unread messages from the same conversation may justify one useful reminder. The content should remain accurate when the person eventually opens it.

I would test frequency changes with a broad set of outcomes. Did replies increase? Did weekly active participation improve? Did complaints and opt-outs increase? Did the apparent gain disappear after the first few days? A sustainable schedule should improve participation without exhausting the audience.

Define every email metric before comparing it

At SkaDate, we track the main email events in Mixpanel: Sent, Delivered, Opened, and Clicked. For our Amazon SES setup, we connect the email events to product analytics ourselves, so we can follow what happens after the user returns: profile completion, a reply, a subscription purchase, or another useful action.

A more integrated service such as SendGrid has built-in email activity and statistics. That can save a new team time. Connecting selected events to Mixpanel can still be useful because it puts email activity next to the rest of the dating user journey.

Regardless of the dashboard, define the events before comparing them. Sent means the sending service accepted a submission; Delivered usually means the recipient’s mail server accepted it. Opened and Clicked are tracked interactions whose limitations we discuss in the next section. These are useful milestones, but they do not all establish that a human read the email.

Send rate can mean throughput, such as messages or recipients submitted per second. It can also be used informally for the proportion of intended notifications that were submitted. These should be separate metrics in your reporting.

Track the funnel from eligible events to actual submissions. If the product decides to send 10,000 notifications but only submits 7,000 because a worker stopped, an excellent downstream delivery rate will hide a substantial failure.

For a defined cohort of attempted recipient deliveries, track provider acceptance, receiving-server acceptance, unresolved deferrals, and failures. Allow enough observation time for the delivery outcome to mature. A message still being retried should not silently disappear from the accounting.

For campaign reporting, the following definitions are a useful starting point:

• Delivery rate: Example definition: Receiving-server acceptances divided by attempted recipient deliveries; Interpretation limit: Does not measure inbox placement.

• Bounce rate: Example definition: Recorded final failures divided by attempted recipient deliveries; Interpretation limit: Depends on classification and observation window.

• Unique open rate: Example definition: Recipients with a tracked open divided by delivered recipients; Interpretation limit: Image fetching is an imperfect proxy for reading.

• Unique click rate: Example definition: Recipients with a tracked click divided by delivered recipients; Interpretation limit: Scanners and bots can create clicks.

• Click to open rate: Example definition: Unique clickers divided by tracked unique openers; Interpretation limit: Inherits uncertainty in both measures.

• Unsubscribe rate: Example definition: Recorded opt-outs divided by delivered recipients; Interpretation limit: State the scope and collection method.

• Product return rate: Example definition: Recipients with a qualifying return divided by the chosen recipient cohort; Interpretation limit: Attribution does not establish causation.

Suppose a hypothetical campaign attempts delivery to 10,000 recipients. It records 9,800 receiving-server acceptances and 300 unique clickers. Under the definitions above, delivery rate is 98% and unique click rate is about 3.06%.

The arithmetic is simple. The interpretation requires care. Some clicks may be automated. Some accepted messages may be in spam. Some people may return without clicking the email, perhaps by opening the app directly.

Also distinguish unique recipients from total events. One person opening five times is different from five people opening once. A message-level view and a person-level view answer different questions.

Complaint rates require especially careful labeling. The complaint events your ESP receives are an incomplete view of recipient behavior, and mailbox providers use their own eligibility and denominator rules. Keep Gmail’s Postmaster rate identified as Gmail’s metric rather than treating it as interchangeable with a campaign dashboard percentage.

Break the results down by mailbox provider, message type, acquisition source, and user cohort. Use enough volume to avoid reacting to statistical noise, while still investigating concrete incidents involving essential account mail.

Email-attributed revenue: connecting emails to purchases

The most important business metric is the revenue attributed to our emails. We should understand which transactional notifications and marketing campaigns bring users back and lead to subscriptions, in-app purchases, or other payments.

An email can serve several purposes at once. A notification tells someone about a new message or like. It also brings that person back into the product, where they may continue a conversation, discover a useful feature, or decide to purchase a subscription.

Consider this example:

1. Daniel receives an email: “Someone liked your profile.”

2. He clicks the email and returns to the app.

3. He visits the likes screen and decides to upgrade.

4. He purchases a $30 subscription.

Under our attribution rules, we can associate that purchase with the email that brought Daniel back.

This means a product notification can contribute to revenue even when the email itself contains no discount or subscription offer. We should measure revenue from both transactional emails and marketing emails.

Track the revenue associated with each email type

Our reporting should help us answer questions such as:

• How much subscription revenue was attributed to new-like notifications?

• Which recommendation emails led to in-app purchases?

• How much revenue was attributed to a reactivation campaign?

• Which email types generate the most revenue relative to the number of people receiving them?

In Mixpanel or another analytics tool, we connect the email interaction with the user’s return and subsequent purchase. This lets us follow the journey beyond Sent, Delivered, Opened, and Clicked.

Measure both total revenue and revenue per recipient

Total attributed revenue tells us how much money is associated with an email campaign or notification type.

Revenue per recipient helps us compare emails sent to audiences of different sizes:

Revenue per recipient = attributed revenue ÷ number of recipients sent the email

Here is a hypothetical example:

• Recipients sent the email: 10,000.

• Purchases attributed to the email: 100.

• Revenue attributed to those purchases: $3,000.

• Revenue per recipient: $0.30.

Under this definition, the campaign generated $0.30 in attributed revenue per recipient. We can compare that figure across campaigns, notification types, and user groups.

Delivery, open, and click metrics help explain how the email performed along the way. Revenue connects those interactions to a business outcome.

Define how a purchase gets credited to an email

Attribution needs a clear rule. For example:

“Credit a purchase to the most recent email the user clicked within the previous 24 hours.”

That is an illustrative rule, not a universal standard. The appropriate window depends on the product and the buying journey.

Use consistent rules when comparing results. Decide whether revenue means the first payment only or also includes later renewals. Also define how you handle refunds and purchases influenced by several channels, such as email, push, and advertising, so the same revenue is not counted multiple times in your overall totals.

Attribution shows which purchases get credited to email under our chosen rules. It does not prove that every credited purchase happened because of the email. Some users would have purchased anyway. Experiments with a holdout group help measure the additional revenue the emails actually create.

For a dating business, the reporting should connect the complete journey: email → return to the product → useful activity → purchase → revenue.

Why opens and clicks require interpretation

Traditional open tracking uses a small remote image. When the email client fetches it, the tracking system records an event. That mechanism observes an image request, which can differ from a person consciously reading the message.

Apple’s Mail Privacy Protection can download remote content in the background regardless of whether the user engages with the email. It also changes the network information exposed to the sender. An apparent open can therefore occur without a human reading the message. [31]

Other factors can make opens disappear. A client may block images, a recipient may read only plain text, or caching may affect repeated requests. The measurement error goes in more than one direction.

Clicks have their own complications. Security systems can fetch links to inspect their destinations. That can create activity before the recipient has interacted. A spike in immediate clicks across every link in a message deserves investigation before anyone celebrates the campaign.

Use the provider’s available bot-filtering features, but retain a realistic view of their limits. A useful product event after the click is stronger evidence of human engagement: an authenticated session, a viewed conversation, a reply, or another meaningful action.

This affects experimentation. Choosing a subject-line winner solely by tracked open rate can reward differences in client mix or automated behavior. A more useful test connects the subject to qualified clicks, returns, and the desired product outcome.

It also affects list hygiene. If a privacy feature generates opens automatically, a person can look engaged in the email tool while being absent from the dating app for months. Use the product’s own activity history when deciding whether ongoing email is appropriate.

Opens remain a directional signal in a consistent context. I would use them alongside other evidence and avoid presenting them as an exact count of people who read the message.

Measure incremental conversations and retention

The strongest question is whether the email program causes additional valuable participation.

Attribution answers which activity followed an email interaction under a chosen rule. Incrementality asks what would have happened without that email. Active users often both click messages and return frequently, so attributing their entire activity to email can overstate the channel’s contribution.

A holdout group helps. For an optional engagement campaign, randomly select eligible users who will not receive it, then compare outcomes over a predefined period. Keep essential account and safety communications outside that marketing experiment.

Here is an illustrative test, not a claim about SkaDate results:

Outcome over the test window:

• Eligible users: Email group: 10,000; Holdout group: 10,000.

• Users who return: Email group: 1,800; Holdout group: 1,500.

• Users who participate in a qualifying conversation: Email group: 600; Holdout group: 450.

The observed return difference is three percentage points, equivalent to 300 additional returns in the treated group under the test’s assumptions. The conversation difference is 1.5 percentage points, equivalent to 150 additional participating users.

If the campaign’s relevant cost were $300, the simple observed cost would be $1 per incremental return or $2 per incremental conversation participant. That is more useful than dividing cost by every return after the send. A real analysis also needs uncertainty estimates and checks that the groups were comparable.

Dating creates an extra complication: users influence one another. An emailed user may reply to someone in the holdout group, improving that other person’s experience. This spillover can affect the measured difference. At sufficient scale, your analyst may use geographic or other suitable clusters, or explicitly account for network effects.

Look beyond the immediate session. Measure later participation, conversations with reciprocal replies, subscription outcomes where relevant, complaints, and opt-outs. Define a qualifying conversation clearly so the metric does not reward empty or abusive message volume.

Retention should reflect the value your product promises. A user who leaves because they formed a successful relationship is different from a user who leaves after finding nobody responsive. Email should help people make progress toward worthwhile interactions and dates.

A practical incident investigation

Suppose support reports that Gmail users are missing message notifications.

First, define the scope. Which stream is affected? When did the problem start? Does it affect Gmail only? Are messages absent, delayed, or found in spam? Are password resets affected too?

Next, trace a few real examples through the system. Confirm that the original product event occurred, the user was eligible, a job was created, and the provider accepted it. Match internal identifiers to provider events.

If the job was never created, investigate product logic. If it is waiting, investigate the queue and worker capacity. If the provider rejected the submission, inspect its error. If the destination deferred or rejected it, inspect the receiving response. If the receiving server accepted it, investigate placement and mailbox behavior with the recipient-side evidence available.

Then compare the timeline with recent changes: DNS edits, a new sender, a provider migration, a large campaign, an acquisition source, or a template deployment. Check Postmaster for the same period, allowing for reporting delays.

The following matrix keeps the investigation focused:

• No provider event: First evidence to inspect: Application event and queue history; Likely action area: Application or worker logic.

• Authentication failure: First evidence to inspect: Original headers and exact DNS identities; Likely action area: Sender configuration.

• Temporary rejection: First evidence to inspect: SMTP response and retry history; Likely action area: Throttling and backoff.

• Invalid-recipient spike: First evidence to inspect: Bounce reasons and signup source; Likely action area: Verification and list quality.

• Complaint spike: First evidence to inspect: Campaign identifiers and audience history; Likely action area: Frequency, content, or consent.

• Accepted but unseen: First evidence to inspect: Recipient folder evidence and Postmaster; Likely action area: Filtering and recipient experience.

• Apple relay failures: First evidence to inspect: Registered sources and authentication; Likely action area: Relay configuration.

Pause the problematic optional stream when necessary while preserving legitimate account operations where feasible. After fixing the cause, resume cautiously and monitor results. Avoid changing several infrastructure variables at once unless the incident requires it.

Write down what happened and the preventive change. If the incident came from a broken unsubscribe sync, the lasting fix is an observable, tested sync with an owner, not merely a one-off database correction.

A reference architecture for a dating product

Here is how I would turn these ideas into a coherent system using the stack discussed in this article.

The application knows the user’s account state, contact address, and notification preferences. It decides whether a useful notification should be sent, then submits the email to Amazon SES using SMTP.

Campaigns are managed through Sendy and sent through Amazon SES. The campaign audience is built from eligible users, with suppression and preference checks that remain effective when new data is imported.

Amazon SES handles email transport, retries, and its configured bounce and complaint suppression. Sendy provides campaign management and supported subscriber handling. The product respects notification preferences and account status, while email events feed the reporting tools.

Postmaster and other destination-specific tools provide an external view. Product analytics connects messages to subsequent sessions, replies, and retention. These are complementary data sources with different coverage.

• Application database: Account state, contact addresses, and preferences.

• Notification decision: Relevance, eligibility, frequency, and channel choice.

• Notification sending: Submit appropriate application emails through SMTP.

• Amazon SES: Sending and provider delivery events.

• Sendy: Marketing audience and campaign workflow.

• Provider delivery reports: Delivery outcomes and configured automatic suppression.

• Postmaster and destination tools: Receiver-side diagnostics.

• Product analytics: Returns, conversations, experiments, and retention.

For a small product, keep the setup understandable. Your sending provider can handle the transport details. Your team needs to configure it, monitor results, and decide which notifications actually help users.

As volume grows, invest where evidence shows a constraint. That may be dedicated IP management, better automation, stronger event retention, more sophisticated preferences, or a different campaign platform. The architecture should allow these changes without losing recipient history or breaking account messages.

The questions I would ask as a founder

You can review your email program without personally editing DNS records.

Ask your team to show a real notification email and confirm that SPF, DKIM, and DMARC pass for your sending domain. Open the provider’s bounce and suppression screens together and check that invalid addresses are handled automatically. Unsubscribe a test account and confirm that optional campaigns stop.

Open Google Postmaster Tools together. Identify any Needs work statuses, explain the spam-rate trend, and compare the period with recent campaigns. If there is no data, establish why and decide what other evidence is available.

Look at your notification inventory from the user’s perspective. Which messages can a person receive in one day? What stops duplication across email and push? What happens after an account is paused, deleted, or moderated? Where does each link take a person on a phone?

Then review the economics. Separate raw sending costs from software and operational costs. Confirm which provider plan is actually active. Make sure the most expensive line items correspond to capabilities your team uses.

Finally, ask for a product result. Which emails increase meaningful participation? Which ones generate activity that would have happened anyway? Which ones create complaints without improving conversations?

The value of understanding SMTP, DNS, authentication, and feedback loops is that you can connect the technical evidence to those business questions. You can distinguish an address-quality issue from a broken worker, a filtering problem from an inaccurate template, and a useful retention experiment from a campaign that merely produces clicks.

When Anna sends Daniel a message, the system should give him a timely, trustworthy opportunity to respond. When he has already responded, it should know that. When he asks for fewer emails, it should remember. When something fails, your team should be able to explain where and why.

That is the email foundation I want underneath a dating business.

Appendix A: A launch and audit checklist

Use this as a working review with the person responsible for your email program.

• Every sending service and domain has an identified owner and documented purpose.

• A real message from each stream passes the intended authentication and alignment checks.

• Forward and reverse DNS meet the requirements of the sending infrastructure.

• The selected Amazon SES region has the required production access and sending capacity.

• The active provider pricing plan and optional features are understood.

• Essential account mail has appropriate priority over campaigns.

• Notifications recheck read state, account state, and eligibility before sending.

• Duplicate tasks and repeated provider events are handled safely.

• Temporary failures have a controlled retry policy and stale notifications expire.

• Invalid addresses and identifiable complaints trigger the appropriate suppression.

• Marketing and subscribed notifications have functional opt-out paths.

• One-click unsubscribe is implemented for the mail that requires it.

• Opt-outs survive imports, queued campaigns, and provider migrations.

• Google and Apple sign-in are configured to use the verified email identity supplied by the service.

• Apple private relay delivery is tested through the actual sending configuration.

• Gmail Postmaster is configured and reviewed by an accountable person.

• Metrics name their denominator, time window, and provider coverage.

• Open and click statistics are interpreted with privacy and automation limitations.

• Important mobile links and fallback destinations work.

• Product experiments measure useful returns and conversations alongside complaints.

Appendix B: Reading a message with your developer

Ask for the full original message from a test mailbox. The following is an illustrative map using reserved example domains; it is not a copy-and-paste configuration.

• Visible From: Example Dating at notifications@notify.example.com.

• Reply-To: support@example.com for human replies.

• Return-Path: A bounce address under bounce.notify.example.com.

• DKIM signing domain: notify.example.com.

• Authentication-Results: Receiver-reported SPF, DKIM, and DMARC results.

• Message-ID: The message identifier used in tracing.

• Feedback-ID: Campaign or stream identifiers for supported aggregate feedback.

• List-Unsubscribe: An HTTPS unsubscribe endpoint for the applicable subscription.

Have the developer identify the domain checked by SPF and the domain signing with DKIM. Compare them with the visible From domain under the configured alignment rules. Then find the provider event for that same message.

For DNS, inspect the records supplied by the sending provider in the authoritative DNS service. SPF and DMARC normally appear as TXT records; DKIM uses the DNS records or aliases supplied by the provider. A custom Amazon SES MAIL FROM domain needs the exact MX and SPF configuration AWS specifies.

The point of this exercise is to connect names that otherwise look abstract. You should be able to see how your brand identity, provider configuration, DNS, and received message relate to one another.

Appendix C: A short glossary

• API: An interface software uses to request work from another system.

• SMTP: Rules used to submit and transfer email.

• POP3: A protocol for retrieving mailbox messages.

• IMAP: A protocol for accessing and synchronizing a server mailbox.

• DNS: The naming system that publishes routing and policy information.

• MX: A DNS record identifying incoming mail servers.

• PTR: A DNS record associating an IP address with a hostname.

• SPF: A policy authorizing infrastructure for an envelope sender identity.

• DKIM: A domain-linked cryptographic message signature.

• DMARC: A policy connecting the visible sender domain to aligned authentication.

• TLS: Encryption protecting a connection between systems.

• ESP: Email service provider.

• Return-Path: The recorded address for delivery failure handling.

• Bounce: A delivery failure.

• Deferral: A temporary refusal that can be retried under a controlled policy.

• Feedback loop: A mechanism providing information about spam complaints.

• Suppression: A rule preventing a message from being sent to an ineligible recipient.

• Spam trap: An address used to detect unwanted sending or poor list practices.

• Warmup: Gradually establishing legitimate sending activity while monitoring responses.

• Webhook: An automated event notification sent between systems.

• Holdout: A comparison group excluded from an optional intervention.

Sources and further reading

Technical documentation and listed pricing checked on October 28–29, 2026. Worked examples in this article are illustrative unless explicitly described as personal experience. Provider interfaces, policies, and prices can change.

[1] Amazon SES — Custom MAIL FROM domains. Open source

[2] IETF — Sender Policy Framework RFC 7208 and linked updates. Open source

[3] IETF — DKIM signatures RFC 6376 and linked updates. Open source

[4] IETF — DMARC RFC 9989 and aggregate reporting RFC 9990. These replace the relevant material in RFC 7489. Open source and Open source

[5] Amazon SES — Shared and dedicated IP considerations. Open source

[6] Spamhaus — Spamhaus Blocklist explanations. Open source

[7] Amazon SES — Requesting production access. Open source

[8] Amazon SES — Event notifications and event data. Open source and Open source

[9] Sendy — Product features and licensing. Open source

[10] Amazon SES — Pricing plans and à la carte pricing. Open source

[11] Resend — Transactional email pricing. Open source

[12] Twilio SendGrid — Email API pricing and links to Marketing Campaigns. Open source

[13] Mailchimp — About Transactional Email. Open source

[14] Yahoo — Complaint Feedback Loop. Open source

[15] Google — Gmail Feedback Loop and Feedback-ID. Open source

[16] Google — Backend authentication and authoritative email identities. Open source

[17] Apple — Receiving a user identity token. Open source

[18] Apple — Configure private email relay service. Open source

[19] Apple — New domain for Sign in with Apple announced August 24 2026. Open source

[20] Spamhaus — Spam traps and the limits of apparent engagement. Open source

[21] Amazon SES — Account-level suppression lists. Open source

[22] IETF — One-click unsubscribe RFC 8058. Open source

[23] Google — Email sender guidelines FAQ including spam thresholds and unsubscribe. Open source

[24] Yahoo — Sender requirements and recommendations. Open source

[25] US Federal Trade Commission — CAN-SPAM compliance guide. Open source

[26] Google — Email sender guidelines. Open source

[27] Microsoft — Outlook high-volume sender authentication requirements. Open source

[28] Google — Postmaster Tools dashboards. Open source

[29] Google — Transition from the legacy Postmaster interface. Open source

[30] Google — Gmail and Postmaster API release notes. Open source

[31] Apple — Mail Privacy Protection and privacy. Open source

[32] Google — Sender requirements and Postmaster Tools FAQ. Open source

Related articles by Alex Sergeev: Retention is King: How to Balance Your Unit Economics; How to Actually Grow a Dating Business; The Foundation: Solving the Cold Start Problem in Dating