Connecting a mailbox

Arvyn sends from your mailbox, not from a shared pool and not from a relay wearing your name. That means one connection method, done properly: SMTP with an app password.

The supported method: SMTP#

Method

SMTP AUTH with an app password

Ports

587 (STARTTLS, preferred) · 465 (implicit TLS)

Encryption

required — plaintext SMTP is refused

Reply reading

IMAP, same credentials

Google OAuth

not supported

Microsoft OAuth

not supported

You will need four values from your provider, and one of them should never be your normal account password.

1. Host — the provider’s SMTP hostname.
2. Port — 587 unless your provider says otherwise.
3. Username — usually the full email address.
4. App password — a credential generated specifically for this connection and revocable on its own.

Why OAuth was removed#

Google and Microsoft OAuth mailbox connections existed and were taken out deliberately. Four reasons, in the order they mattered.

• The scopes are too broad for the job. Sending mail through OAuth requires consenting to scopes that grant far more access to the mailbox than sending needs. An app password is narrower and it is obvious to the person granting it exactly what it can do.
• Tokens fail silently. Refresh tokens are revoked by password changes, admin policy updates, security reviews and inactivity. The failure surfaces as sends stopping, usually noticed a day later. An app password fails immediately and visibly, at authentication.
• Verification puts a third party between you and your mail. Restricted scopes require app verification and periodic security assessment, and the result is that your ability to send from your own mailbox depends on someone else’s review queue.
• One path, maintained properly. Two connection methods means two sets of failure modes, two sets of documentation and two things to get subtly wrong. SMTP works identically on every provider.

Google Workspace and Gmail#

App passwords require 2-Step Verification to be switched on for the account first.

Host

smtp.gmail.com

Port

587 (STARTTLS)

Username

the full address, e.g. you@yourdomain.com

Password

a 16-character app password

IMAP host

imap.gmail.com, port 993

1. Turn on 2-Step Verification for the sending account.
2. Go to the Google Account security settings and open App passwords.
3. Create one, name it for this connection, and copy the generated value.
4. In Google Workspace, confirm IMAP is enabled for the user under Gmail settings — reply reading needs it.

If app passwords are unavailable#

On Workspace accounts, an administrator can switch app passwords off for the whole organisation. If the option is missing entirely, that is the reason — it is a policy setting, not a bug on your account. The options are to have the admin allow it, or to send from a separate outbound domain where you control the policy. The second is usually better for other reasons anyway.

Microsoft 365 and Outlook#

Host

smtp.office365.com

Port

587 (STARTTLS)

Username

the full address

Password

an app password, where the tenant permits them

IMAP host

outlook.office365.com, port 993

Two tenant-level settings decide whether this works at all.

• SMTP AUTH must be enabled for the mailbox. It is disabled by default on many tenants and is set per-mailbox by an administrator, not by the user.
• App passwords must be permitted. They are available only when multi-factor authentication is configured in a way that allows them, and security defaults being on will normally block them.

Other providers#

SPF, DKIM and DMARC#

These are not optional. A mailbox whose domain fails authentication will be accepted by the connection form and then quietly fail to reach inboxes, which is the worst of both. Arvyn checks all three and will not begin warmup until they resolve.

SPF#

One TXT record at the domain root, listing who may send for you. There must be exactly one SPF record — two is a permanent failure, not a merge.

yourdomain.com.   IN   TXT   "v=spf1 include:_spf.google.com ~all"

DKIM#

Generated by your provider and published at a selector subdomain. Turn it on in the provider’s admin console, publish the record it gives you, then return to the console and switch signing on — in that order, or the first signed messages fail verification.

google._domainkey.yourdomain.com.   IN   TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

DMARC#

Start at p=none with reporting on, read the reports for a fortnight, then tighten. Publishing p=reject on day one on a domain you have not yet observed is how legitimate mail from systems you forgot about starts disappearing.

_dmarc.yourdomain.com.   IN   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s"

Verifying the connection#

Saving a mailbox triggers three checks. All three must pass before the mailbox is eligible for campaign traffic.

You can run the same checks yourself before you start.

# SPF — exactly one record should come back
dig +short TXT yourdomain.com | grep spf1

# DMARC
dig +short TXT _dmarc.yourdomain.com

# DKIM, replacing the selector with your provider's
dig +short TXT google._domainkey.yourdomain.com

# STARTTLS handshake and AUTH advertisement
openssl s_client -starttls smtp -crlf -connect smtp.gmail.com:587

In the openssl output, look for 250-AUTH in the server’s capability list. If it is absent, SMTP authentication is disabled for that host or that mailbox and no credential will help.

Troubleshooting#

Next: deliverability — warmup, pacing, and the tracking default.